In POJO Java beans such code can be beneficial, especially with collections:
class POJO {
private Collection<
I do not see it as a good practice, more as some very rarely needed optimization. Maybe lazy initialization can make sense if SomeCollection is extremely heavy to create. Instead you can initialize it when declared (code is cleaner at least for my eyes):
class POJO {
private Collection<X> col = new SomeCollection<X>();
public Collection<X> getCol() {
return col;
}
}
There is no side effects in flush or portability issues and you have one null check less.
I would strongly discourage lazy initialization for properties in an ORM entity.
We had a serious issue when doing lazy initialization of an entity property using Hibernate, so I would strongly discourage it. The problem we saw was manifest by a save taking place when we were issuing a search request. This is because when the object was loaded the property was null, but when the getter was called it would return the lazy initialized object so hibernate (rightly) considered the object dirty and would save it before issuing the search.
Lazy initialization is very common and fine to do.
There are trade-offs versus initializing in the constructor or variable definition:
Pro
Con
In general it is a good idea to use empty collections instead or null (for fields that are collections).
But I don't recommend the way you do in the getter.
In my personal opinion the "rule" above should also be used for the internal representation of the object too. So you go better with:
class POJO {
private Collection<X> col = new SomeCollection<X>();
Anyway if you want want to make it more save, you need to guard every way you update the col
reference. But in a JPA application this should be a very raw use case.