Is there any way to declare final fields for Hibernate-managed objects?

Question

I'm just getting started with Hibernate, and all the examples I'm seeing so far look pretty much like the tutorial in the Hibernate documentation:

package org.hibernate.tutorial.domain;
import java.util.Date;

public class Event {

    private Long id;
    private String title;
    private Date date;

    public Event() {}

    /* Accessor methods... */
}

Specifically: none of the fields are declared as 'final', and there must be a no-argument constructor so that the Hibernate framework can instantiate the class and set its fields.

But here's the thing - I really don't like making my classes mutable in any way whenever I can avoid it (Java Practices: Immutable Objects make a pretty strong argument for doing this). So is there any way to get Hibernate to work even if I were to declare each of the fields 'final'?

I understand that Hibernate uses Reflection to instantiate its classes and therefore needs to be able to invoke a constructor of some sort without taking the risk that it would pick the wrong constructor or pass the wrong value to one of its parameters, so it's probably safer to invoke the no-arg constructor and set each field one at a time. However, shouldn't it be possible to provide the necessary information to Hibernate so that it can safely instantiate immutable objects?

public class Event {

private final Long id;
private final String title;
private final Date date;

public Event(@SetsProperty("id") Long id,
    @SetsProperty("title") String title,
    @SetsProperty("date") Date date) {

    this.id = id;
    this.title = title;
    this.date = new Date(date.getTime());
}

/* Accessor methods... */

}

The @SetsProperty annotation is of course fictitious, but doesn't seem like it should be out of reach.

Answer 1

Just remove the finals. Final is not essential for an immutable object.

Answer 2

This sounds like it is not a use case for Hibernate, since many operations it performs concern mutable state:

• merging objects
• dirty state checking
• flushing changes

That being said, if you're concerned about immutability you may choose to provide wrappers around your objects, with copy-constructors:

public class FinalEvent {
    private final Integer id;

    public FinalEvent(Event event) {
        id = event.id;
    }
}

It does mean extra work though.

---

Now that I'm thinking of it, hibernate sessions are usually thread-bound and this voids at least one the benefits of the final fields - safe publication.

What other the benefits of final fields are you looking for?

Answer 3

Immutable object means an object with no methods that modify its state (i.e. its fields). The fields needn't be final. So you can remove all mutators and configure Hibernate to use fields acces instead of accessors or you can just mark no-arg constructor and mutators as deprecated. It's a bit workaround but better that than nothing.

Answer 4

You may be able to accomplish the desired result by using a Builder pattern. I read a posting a while ago on the Hibernate Forums discussing the idea (though I never implemented it myself...)

Answer 5

This one has been bugging me for a long time too. One idea I've been trying out recently is this - define read-only interfaces for your model classes and have your DAOs and any factories return those instead on the object. That means that even though the implementation is mutable, once it's left the DAO/factory object it can no longer be tweaked.

Like so:

public interface Grape {
  public Color getColor();
}

public class HibernateGrapeDao {
  public Grape findGrape(int grapeId) {
    HibernateGrape grape = hibernate.find(...
    return grape;
  }
}

class HibernateGrape implements Grape {
 ....
}

May even want to keep the implementing classes package-private to the dao package, so nobody can fiddle with them directly. A bit more work, but probably helps keep things cleaner in the long run. And, obviously, be careful with the whole equality/identity business.

Answer 6

Actually in JDK 1.5+ hibernate can handle (thru reflection) changing final fields. Create a protected default constructor() that sets the fields to some defaults/null etc... Hibernate can and will override those values when it instantiates the object.

This is all possible thanks to changes to Java 1.5 memory model - the changes of interest (allowing final to be not so final) where made to enable serialization/deserialization.

So...

public class Event {

final private Long id;
final private String title;
final private Date date;

// Purely for serialization/deserialization
protected Event() {
    id = null;
    title = null;
    date = null;
}

public Event(Long id, String title, Data date) {
    this.id = id;
    this.title = title;
    this.date = date;
}

/* Accessor methods... */

}