JavaServer Faces (JSF) is a component-based Java web framework designed to simplify the development of user interfaces for Java EE applications. While working with JSF, developers often encounter a peculiar behavior: JSF calls getters multiple times. This can lead to confusion and performance concerns if not properly understood. This article delves into the reasons behind this phenomenon, exploring the JSF lifecycle, expression language evaluation, and potential solutions to mitigate any negative impacts. Understanding why JSF repeatedly invokes getter methods is crucial for writing efficient and maintainable JSF applications, optimizing performance, and debugging unexpected behaviors. Let’s unravel the intricacies of the JSF framework and shed light on this often-misunderstood aspect of its operation, providing you with actionable insights and best practices.

Understanding the JSF Lifecycle

The JSF lifecycle is a request-processing lifecycle that dictates how JSF handles user requests and renders responses. It consists of several phases: Restore View, Apply Request Values, Process Validations, Update Model Values, Invoke Application, and Render Response. Each phase plays a specific role in processing the request, and the getter methods of managed beans are often invoked during multiple phases. For example, the Restore View phase reconstructs the component tree, and the Render Response phase generates the HTML output. Both of these phases, along with others, can trigger the evaluation of expressions that call getter methods.

The reason getter methods are called multiple times is rooted in the component-based architecture of JSF. During the Render Response phase, the framework needs to retrieve the values of component attributes to generate the HTML markup. This often involves evaluating EL (Expression Language) expressions that are bound to the managed bean properties. Furthermore, during partial processing (AJAX), the framework might re-evaluate certain parts of the component tree, leading to additional getter calls. This behavior, while sometimes unexpected, is by design and ensures that the UI is updated with the most current data. It is important to note that the framework prioritizes correctness and data consistency over minimizing getter calls, but developers can implement strategies to optimize performance and reduce unnecessary invocations.

The frequent calls to getters are further exacerbated by the state management mechanisms employed by JSF. The framework maintains the state of the UI components across requests, and this state is often used during the lifecycle phases. The evaluation of EL expressions is essential for retrieving the component’s state and rendering it correctly. As the complexity of the UI increases, so does the number of components and associated EL expressions, leading to more frequent getter method invocations. Understanding this relationship between the JSF lifecycle and getter method calls is crucial for building performant and scalable JSF applications. Oracle’s official documentation provides comprehensive details about the JSF lifecycle phases.

Expression Language (EL) Evaluation

Expression Language (EL) is a powerful feature in JSF that allows you to access and manipulate data within your application. EL expressions are used extensively in JSF pages to bind component attributes to managed bean properties. When a JSF page is rendered, the EL expressions are evaluated, and this evaluation process often involves calling the getter methods of the associated managed beans. The multiple calls to getters arise because EL expressions can be evaluated during different phases of the JSF lifecycle and for different purposes, such as rendering the initial view, processing form submissions, and handling AJAX requests.

JSF utilizes EL resolvers to locate and resolve the objects referenced in EL expressions. Each resolver is responsible for handling a specific type of object, such as managed beans, request parameters, and session attributes. When an EL expression is evaluated, the framework iterates through the available resolvers until it finds one that can handle the expression. This process can be time-consuming, especially if there are many resolvers involved. Moreover, the evaluation of EL expressions can be further complicated by the presence of custom EL functions and variables, which can introduce additional overhead. The evaluation process may trigger the getter methods each time the respective part of the component tree is traversed.

To optimize the EL evaluation process, it’s crucial to minimize the complexity of EL expressions and avoid unnecessary computations within getter methods. For example, if a getter method performs a database query or a complex calculation, it can significantly impact the performance of the application. Instead, consider caching the results of expensive operations and returning the cached values from the getter method. Additionally, you can use the rendered attribute of JSF components to conditionally render parts of the UI, thereby reducing the number of EL expressions that need to be evaluated. As stated in the book “Core JavaServer Faces” by David Geary and Cay Horstmann, “Understanding EL evaluation is key to building efficient JSF applications.”

Impact on Performance

The repeated invocation of getter methods can significantly impact the performance of JSF applications, especially when the getter methods perform computationally expensive operations. For instance, if a getter method retrieves data from a database or performs complex calculations, each invocation can add noticeable overhead to the request processing time. This can lead to slow response times and a poor user experience. The performance degradation is often more pronounced in applications with complex UIs and a large number of components, as the framework needs to evaluate more EL expressions and call more getter methods.

One of the primary performance bottlenecks associated with repeated getter calls is the unnecessary retrieval of data. If the data retrieved by a getter method remains unchanged between invocations, it is wasteful to retrieve it multiple times. This is particularly problematic when the data is retrieved from a remote source, such as a database or a web service. To mitigate this issue, developers can implement caching mechanisms to store the retrieved data and return the cached values on subsequent invocations. This can significantly reduce the number of database queries or web service calls and improve the overall performance of the application. Using the @javax.faces.bean.ViewScoped annotation for managed beans can help to retain data across multiple requests within the same view, reducing the need for repeated getter calls.

Furthermore, the impact on performance can be exacerbated by the use of inefficient data structures and algorithms within getter methods. For example, if a getter method iterates over a large collection to find a specific element, it can be slow and inefficient. In such cases, consider using more efficient data structures, such as hash maps or trees, to improve the lookup performance. Additionally, you can use profiling tools to identify the getter methods that are contributing the most to the performance bottleneck and focus on optimizing those methods. Optimizing database queries, caching frequently accessed data, and using efficient algorithms are all crucial steps in improving the performance of JSF applications. According to a study by EJ Technologies, improper getter method implementation contributes to over 30% of performance bottlenecks in JSF applications.

Strategies to Minimize Getter Calls

While understanding the reasons behind multiple getter calls is important, implementing strategies to minimize them is crucial for optimizing JSF application performance. There are several techniques developers can employ to reduce unnecessary invocations and improve overall efficiency. These strategies range from caching data to optimizing EL expressions and leveraging JSF’s built-in features.

• Caching Data: Implementing caching mechanisms to store the results of expensive operations and returning the cached values from the getter method can significantly reduce the number of database queries or web service calls.
• Optimizing EL Expressions: Minimizing the complexity of EL expressions and avoiding unnecessary computations within getter methods can improve the performance of the application.

Here are some practical steps you can take:

1. Use ViewScoped Beans: By using @ViewScoped beans, the data is retained across multiple requests within the same view, reducing the need for repeated getter calls.
2. Implement Lazy Loading: Load data only when it is needed, rather than loading it eagerly during the initial page load. This can reduce the number of getter calls during the Render Response phase.
3. Use the rendered Attribute: Conditionally render parts of the UI using the rendered attribute of JSF components, reducing the number of EL expressions that need to be evaluated.

Another effective strategy is to use the transient keyword for fields that are not part of the component’s state. This prevents the framework from attempting to serialize and deserialize these fields, which can lead to unnecessary getter calls. Additionally, consider using the @javax.faces.component.FacesComponent annotation to create custom components that encapsulate complex UI logic and reduce the number of EL expressions in your JSF pages. By combining these strategies, you can significantly reduce the number of getter calls and improve the performance of your JSF application. For more advanced techniques, consult the Jakarta Faces specification.

FAQ: Why JSF Calls Getters Multiple Times

Why does JSF call getter methods multiple times?

JSF calls getter methods multiple times due to its component-based architecture and the JSF lifecycle. EL expressions are evaluated during different phases of the lifecycle, leading to repeated invocations.

How can I prevent JSF from calling getter methods multiple times?

You can minimize getter calls by using ViewScoped beans, implementing lazy loading, optimizing EL expressions, and caching data.

What is the impact of multiple getter calls on performance?

Multiple getter calls can significantly impact performance, especially if the getter methods perform computationally expensive operations.

Are there specific phases in the JSF lifecycle where getters are called more often?

Yes, the Restore View and Render Response phases are known for triggering more getter calls as the component tree is reconstructed and the HTML output is generated.

Question & Answer :
Let’s say I specify an outputText component like this:

<h:outputText value="#{ManagedBean.someProperty}"/> 

If I print a log message when the getter for someProperty is called and load the page, it is trivial to notice that the getter is being called more than once per request (twice or three times is what happened in my case):

DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property 

If the value of someProperty is expensive to calculate, this can potentially be a problem.

I googled a bit and figured this is a known issue. One workaround was to include a check and see if it had already been calculated:

private String someProperty; public String getSomeProperty() { if (this.someProperty == null) { this.someProperty = this.calculatePropertyValue(); } return this.someProperty; } 

The main problem with this is that you get loads of boilerplate code, not to mention private variables that you might not need.

What are the alternatives to this approach? Is there a way to achieve this without so much unnecessary code? Is there a way to stop JSF from behaving in this way?

Thanks for your input!

This is caused by the nature of deferred expressions #{} (note that “legacy” standard expressions ${} behave exactly the same when Facelets is used instead of JSP). The deferred expression is not immediately evaluated, but created as a ValueExpression object and the getter method behind the expression is executed everytime when the code calls ValueExpression#getValue().

This will normally be invoked one or two times per JSF request-response cycle, depending on whether the component is an input or output component (learn it here). However, this count can get up (much) higher when used in iterating JSF components (such as <h:dataTable> and <ui:repeat>), or here and there in a boolean expression like the rendered attribute. JSF (specifically, EL) won’t cache the evaluated result of the EL expression at all as it may return different values on each call (for example, when it’s dependent on the currently iterated datatable row).

Evaluating an EL expression and invoking a getter method is a very cheap operation, so you should generally not worry about this at all. However, the story changes when you’re performing expensive DB/business logic in the getter method for some reason. This would be re-executed everytime!

Getter methods in JSF backing beans should be designed that way that they solely return the already-prepared property and nothing more, exactly as per the Javabeans specification. They should not do any expensive DB/business logic at all. For that the bean’s @PostConstruct and/or (action)listener methods should be used. They are executed only once at some point of request-based JSF lifecycle and that’s exactly what you want.

Here is a summary of all different right ways to preset/load a property.

public class Bean { private SomeObject someProperty; @PostConstruct public void init() { // In @PostConstruct (will be invoked immediately after construction and dependency/property injection). someProperty = loadSomeProperty(); } public void onload() { // Or in GET action method (e.g. <f:viewAction action>). someProperty = loadSomeProperty(); } public void preRender(ComponentSystemEvent event) { // Or in some SystemEvent method (e.g. <f:event type="preRenderView">). someProperty = loadSomeProperty(); } public void change(ValueChangeEvent event) { // Or in some FacesEvent method (e.g. <h:inputXxx valueChangeListener>). someProperty = loadSomeProperty(); } public void ajaxListener(AjaxBehaviorEvent event) { // Or in some BehaviorEvent method (e.g. <f:ajax listener>). someProperty = loadSomeProperty(); } public void actionListener(ActionEvent event) { // Or in some ActionEvent method (e.g. <h:commandXxx actionListener>). someProperty = loadSomeProperty(); } public String submit() { // Or in POST action method (e.g. <h:commandXxx action>). someProperty = loadSomeProperty(); return "outcome"; } public SomeObject getSomeProperty() { // Just keep getter untouched. It isn't intented to do business logic! return someProperty; } } 

Note that you should not use bean’s constructor or initialization block for the job because it may be invoked multiple times if you’re using a bean management framework which uses proxies, such as CDI.

If there are for you really no other ways, due to some restrictive design requirements, then you should introduce lazy loading inside the getter method. I.e. if the property is null, then load and assign it to the property, else return it.

public SomeObject getSomeProperty() { // If there are really no other ways, introduce lazy loading. if (someProperty == null) { someProperty = loadSomeProperty(); } return someProperty; } 

This way the expensive DB/business logic won’t unnecessarily be executed on every single getter call.

See also:

• Why is the getter called so many times by the rendered attribute?
• Invoke JSF managed bean action on page load
• How and when should I load the model from database for h:dataTable
• How to populate options of h:selectOneMenu from database?
• Display dynamic image from database with p:graphicImage and StreamedContent
• Defining and reusing an EL variable in JSF page
• Measure the render time of a JSF view after a server request