I' have a question about initialization of List in the POJO as it follows the next code:
public class Person {
//other fields...
private List<String> friends=new ArrayList<>();
public List<String> getFriends() {
return friends;
}
public void setFriends(List<String> friends) {
this.friends = friends;
}
}
OR is it better like this and have initalization in other class(like for example Bean(JSF))
public class Person {
//other fields...
private List<String> friends;
public List<String> getFriends() {
return friends;
}
public void setFriends(List<String> friends) {
this.friends = friends;
}
}
So my question is what approach is better?
If it's a managed bean as you say, you should do this in a method annotated with @PostConstruct
public class Person {
private List<String> friends;
@PostConstruct
public void init(){
friends = new ArrayList<String>();
}
//getter and setter...
}
The practice of doing any initialization in the getter and setter is generally frowned upon within the context of JSF. See Why JSF calls getters multiple times
Also, per the API for @PostConstruct
, the contract specifies safety features and guarantees that if an exception is thrown in a method annotated as such, the bean should not be put into service. There are no such guarantees on a plain constructor.
In a managed bean, injection happens immediately after construction. This means that any operations you're carrying out in the constructor cannot depend on any injected resources (via @ManagedProperty
). Whereas in a @PostConstruct
method, you'll have access to all the resources declared on the managed bean
EDIT: It's important to note that there can be only one @PostConstruct
for any @ManagedBean
, so all important initializations should happen in there.
It's also worthwhile to note that, while the @PostConstruct
method is the ideal place to initialize a backing bean variable/List
, there are implications regarding the scope of the managed bean
@RequestScoped
: In a managed bean with this annotation, the method will be called per submit of the JSF view concerned. A @RequestScoped
bean is destroyed and recreated with every request, The implication of this is that depending on your setup, the list initialized in the @PostConstruct
may be reset to empty or default values during each request. Under certain circumstances, conversion errors may occur as a result of the re-initialization of the list mid-JSF request.
@ViewScoped
: In a managed bean with this annotation, you're guaranteed to have the @PostConstruct
method run once, if and only if you're dealing with the same instance of the @ViewScoped
bean. If the viewscoped bean is destroyed and recreated, the @PostConstruct
method will run again.
@SessionScoped
: A bean with this annotation is created once and stays alive until the user's HTTP session ends. In this scenario, the @PostConstruct
method is guaranteed to run once and only once until the bean is destroyed
See also