In the company that I work for we have this major discussion on whether it should be better to use wrapping classes for primitives (java.lang.Integer, java.lang.Long) or whether to use the primitive types directly in the POJOs that map Entities to Tables in Hibernate. The idea is that we want these values to not be null in the database. The arguments in favor of using primitives: Handling these values as int means that they can never be null, in this way making it impossible to inadvertently get a null reference on the field. int=32/64 bits of memory. Integer = 16 bytes of memory and is also slower The arguments in favor of using wrapper objects: We can add a constraint at the database level to always prevent null values from getting there We can end up with misleading data, we can have 0's instead of nulls in the database whenever the user doesn't set a value and buggy data is a tough catch. Objects have more expressive power than primitives. We have null values and also integer values, so we can validate them easier using annotations for example (javax.validation.constraints.NotNull).

Reputation: 979

Using wrapper Integer class or int primitive in hibernate mapping

In the company that I work for we have this major discussion on whether it should be better to use wrapping classes for primitives (java.lang.Integer, java.lang.Long) or whether to use the primitive types directly in the POJOs that map Entities to Tables in Hibernate.

The idea is that we want these values to not be null in the database.

The arguments in favor of using primitives:

Handling these values as int means that they can never be null, in this way making it impossible to inadvertently get a null reference on the field.
int=32/64 bits of memory. Integer = 16 bytes of memory and is also slower

The arguments in favor of using wrapper objects:

We can add a constraint at the database level to always prevent null values from getting there
We can end up with misleading data, we can have 0's instead of nulls in the database whenever the user doesn't set a value and buggy data is a tough catch.
Objects have more expressive power than primitives. We have null values and also integer values, so we can validate them easier using annotations for example (javax.validation.constraints.NotNull).

Upvotes: 51

Answers (5)

Pritam Rajput

Reputation: 118

If you are using a database like mongo db, OR the data has meaning when its null go with Wrapper,

Tip: If you are doing calculations just create an extraNullChecked getter and use that to avoid null checks all over the codebase.

If the Data point has to have a value all the time and can't be null, use primitive.

Upvotes: 0

Krusty the Clown

Reputation: 723

I'm gonna go out on a limb and disagree with all of the other answers here. If the field is nullable in the database, use a wrapper. If it can't be null, use a primitive. Now you get the performance benefits, AND it's much easier to distinguish between fields that can and can't be null in your code.

Upvotes: 0

yair

Reputation: 9245

Thought it should be mentioned:

Hibernate recommendation (section 4.1.2) using non-primitive properties in persistent classes actually refers - as titled - to identifier properties:

4.1.2. Provide an identifier property

Cat has a property called id. This property maps to the primary key column(s) 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.

...

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

Nonetheless, the advantages of primitives aren't strong:

Having an inconsistent non-null value in a property is worse than NullPointerException, as the lurking bug is harder to track: more time will pass since the code is written until a problem is detected and it may show up in a totally different code context than its source.
Regarding performance: before testing the code - it is generally a premature consideration. Safety should come first.

Upvotes: 16

Matthew Farwell

Reputation: 61705

Use wrappers, make your life simple.

Your data model should dictate this. You should be enforcing nullability in the database anyway.

If they are nullable in the database, then use wrappers. If they are not nullable, and you use wrappers, then you'll get an exception if you try and insert a null into the database.

If your data model doesn't dictate it, then go for a convention, use wrappers all of the time. That way people don't have to think, or decide that a value of 0 means null.

I would also query your assertion that it would less performant. Have you measured this? I mean really measured it? When you're talking to a database, there are a lot more considerations than the difference between 16 bits and 32 bits.

Just use the simple, consistent solution. Use wrappers everywhere, unless somebody gives you a very good reason (with accurate measured statistics) to do otherwise.

Upvotes: 48

Jon Skeet

Reputation: 1500675

The Hibernate documentation (just the first version I happened to find) states:

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.

...

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

So the "expert's voice" suggests using Integer / Long... but it's not described why this is the case.

I wonder whether it's so that an object which hasn't been persisted yet can be created without an identifier (i.e. with a property value of null), distinguishing it from persisted entities.

Upvotes: 7

Using wrapper Integer class or int primitive in hibernate mapping

Answers (5)

4.1.2. Provide an identifier property

Related Questions