Hello.

I am relatively new to Hibernate, and I recently had a heated debate about using native java primitives vs. Wrapper classes..

I'd like to know more about the motives behind use of wrapper classes vs. Natives if you guys can either point to the article or reference.

For example...

We have a column in the database that stores true or false. We store them as bit(1) with a default value of 0.

Is it better to use the 'boolean' or 'Boolean', and why latter over former?

I realized that hibernate takes of 'null' value, but with default '0', shouldn't that value be handled better with 'boolean'?

Besides the memory footage, I hate getting a "NPE" when I am trying to read the value for this column and the value doesn't exist whereas I would get a 'false' which would be appropriate for a business sense.


Any thoughts and inputs are highly appreciated~.

Regards.

I have never given much thought about it but I only use wrapper classes when a use-case requires null values. This is quite rare so I think that in 90% or more of the cases I use primitive values.

In what situation would null value useful for Boolean or number types?

Academically, sure. But in practical business sense?

Here are some examples:

* We have some numeric values for storing the used quantity of some compound in a experiment. Sometimes the numbers are not important and are stored as null, and sometimes they are are...

* It is possible to upload files and attach them to an experiment. We have implemented validators that check if the file is properly formatted, etc. But we only have validators for some files that contain data that is important to the experiment. So we have a Boolean were null=not validated, true=a valid file, false=an invalid file.

Seems like a limited use cases then more common situation.

Don't get me wrong. I do see the cases where null is a valid case. However, the cases are special then a norm.

A check box in the UI is a Boolean. Is there is no value, a default false is more than sufficient. Seems like a same cases for other primitive types for me.

The reason why I bring this up is simple. My partner argues that using a primitive is WRONG, with or without hibernate. And while I see his point, I simply can't agree.

His another point is that you will get a null-cLue assignment error If the value in the db is null. That to me is just being lazy for noy assigning a default in th db. All modern DBMS allow the default assigment if not provided.

Is there something I am missing here? Is it really better to check for NPE for these primitive values instead of having a default? He says that hibernate recommend wrappers over primitives. Where can I find these articles?

I agree. And my point is that if there is no use case for null values then it's better to use primitive types. If there is no use case for null values and you still allow null values in the db and by using wrapper classes, that NPE will bite you sooner or later.



If you use primitive types database should be configured to not allow null values. If you have control over the database design this should be no problem. If you need to work against a legacy database that you can't change it's a different situation. If a column can contain null values then I would use a wrapper class and hope that I remember to check this every time i use the value somewhere.



Except for id values, I don't think I have seen any recommendation to use wrappers. In the case of id values it is simply because it makes it easier to tell if an entity is a new not yet persisted entity or not.

Thanks for the responses.

Your comments agree completely with that of mine.

I will have to bring this up again with my partner, or point to this post.

I am sure he has seen or read somewhere where use of wrapper makes more appropriate use, but since I haven't seen one and since I am new to hibernate, I thought I ask for more opinions.

Cheers.

This is not really related to Hibernate or how you represent things in the database, but is an example of a difference that matter when it comes to using primitive versus wrapper types.

Today a colleague of mine had a problem with removing items from a List. In principle the code was as simple as below, except that variable declaration was a bit more spread out so it was not immediately visible that index was an Integer.



The problem was that nothing was removed from the list. The list had some elements and no matter what the index was nothing happened. Didn't even get ArrayIndexOutOfBoundsException:s when trying index values outside the size of the list...

Hmmm.... turned out that List.remove() comes in two variants:



where the first removes an object by index and the latter removes the specified object. The code above calls the List.remove(Object) method and since the the list contained String objects and not Integer objects nothing was removed.

So the bottom line is that auto-boxing of wrapper classes is not always your friend. Consider, for example, the case when an API evolves. In the first version there is only Foo.remove(int) and your code works fine because of auto-boxing. In the second version the Foo.remove(Objects) method is added. If you recompile your code against the new API it calls the new remove(Object) method which may cause problems.

That's a good point.

I ran into such issues that are caused by the auto-boxing. Mostly in the form of NPE.

long id = maps.get(key);

If the value is not found, then instead of getting a null, you get a NPE.

Personally, there are more things that I dislike about the feature than the convenience it provides.