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

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?