Primitive or wrapper for hibernate primary keys

From an Hibernate point of view, it doesn’t change anything as Hibernate uses the same Hibernate type to represent them.

However, as pointed out by Bytecode Ninja, you can’t distinguish the default value of a primitive int 0 from a an assigned 0 while there is no possible ambiguity with a null (a null id always means a new entity), which is why I prefer to use a nullable wrapper type.

And this is the Hibernate recommendation. From the Reference Documentation:

4.1.2. Provide an identifier property (optional)

Cat has a property called id. This
property maps to the primary key
column of a database table. The
property might have been called
anything, and its type might have been
any primitive type, any primitive
“wrapper” type, java.lang.String or
java.util.Date. If your legacy
database table has composite keys, you
can use a user-defined class with
properties of these types (see the
section on composite identifiers later
in the chapter.)

The identifier property is strictly
optional. You can leave them off and
let Hibernate keep track of object
identifiers internally. We do not
recommend this, however.

In fact, some functionality is
available only to classes that declare
an identifier property:

• Transitive reattachment for detached objects (cascade update or cascade
  merge) – see Section 10.11,
  “Transitive persistence”
• Session.saveOrUpdate()
• Session.merge()

We recommend that you declare
consistently-named identifier
properties on persistent classes and
that you use a nullable (i.e.,
non-primitive) type.

And I actually leverage this in my base class:

@MappedSuperclass
public class BaseEntity implements Serializable {
    private static final long serialVersionUID = 1L;
    private Long id;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Transient
    public boolean isNew() {
        return (this.id == null);
    }
}