Java


Exonerating the JSF Lifecycle

One of the many accusations aimed at JSF is the definition and complexity of the JSF Lifecycle. The JSF lifecycle is responsible for processing the page creation and submission and orchestrates the different pieces of the framework. A more thorough description of the process can be found in this article by Rick Hightower. At a high level, this process is defined as :

  1. Restore View – JSF builds the view for the first time or restores the component tree.
  2. Apply Request Values – take the values from the submitted form, convert them and put them in the component objects.
  3. Process Validation – validates the converted values based on applicable validators. If validation fails, we jump to the last step.
  4. Update Model Values – take the converted and validated values and put them in the properties of the backing bean.
  5. Invoke Application – Once your backing beans have been updated, the application is called and usually code is executed against the backing beans.
  6. Render Response – the response is generated and sent back to the users browser.

It is claimed that it is an unnecessary complexity that the developers must deal with in order to use JSF. Understanding the lifecycle is not a requirement but will help you understand what is going on, but what is objectionable about this assertion is that this lifecycle is no different than just about any other web framework. One Spring MVC user has posted a cheat sheet which is quite a handy guide to the form controller. It shows how complex Spring MVC can be in executing identical behavior. Wicket and even ASP.net perform the same steps in that it utilizes a server side model, pushes the values in, converts and validates them, handles events, and then renders a response. Even the most simplistic frameworks must always extract values, convert and validate them since when working in the web, you are merely pushing strings between server and client. At some point these string values be converted to meaningful data and objects and the consequences of invalid content must be dealt with. JSF is quite upfront about this process and even lets you hook in to the lifecycle events through the JSF PhaseListener.

Comparing Constants Safely

When comparing two objects, the equals method is used to return true if they are identical. Typically, this leads to the following code :

if (name.equals("Jim")) {
}

The problem here is that whether intended or not, it is quite possible that the name value is null, in which case a null pointer exception would be thrown. A better practice is to execute the equals method of the string constant “Jim” instead :

if ("Jim".equals(name)) {
}

Since the constant is never null, a null exception will not be thrown, and if the other value is null, the equals comparison will fail.

If you are using Java 7 or above, the new Objects class has an equals static method to compare two objects while taking null values into account.

if (Objects.equals(name,"Jim")) {
}

Alternatively if you are using a java version prior to Java 7, but using the guava library you can use the Objects class which has a static equal() method that takes two objects and handles null cases for you. It should also be noted that there are probably a number of other implementations in various libraries (i.e. Apache Commons)

Immutability Through Interfaces

It is often desirable to have immutable objects, objects that cannot be modified once constructed. Typically, an immutable object has fields that are declared as final and are set in the object constructor. There are getters for the fields, but no setters since the values cannot be saved. Once created, the object state doesn’t change and the objects can be shared across different threads since the state is fixed. There are plenty of caveats to that statement, for example if you have a list, while the list field reference may be final, the list itself may be able to change and have values added and removed which would spoil the immutability.

Achieving this state can often be difficult because we rely on a number of tools and frameworks that may not support immutability such as any framework that builds an object by creating it and then setting values on it.

However, one way around this would be to take a mutable object and make it immutable through interfaces. We do this by creating an interface that represents all the getters for an object, but none of the setters. Read More »

Java 8 features key to adoption

A new report by Typesafe indicates two thirds of developers plan on adopting Java 8 within the next year, with most of them aiming to adopt within 6 months.

New versions of Java have always been slow to gain adoption among both developers and to a larger extent, the public. This has often led to frustrations with regards to deploying projects on outdated versions of java. Every few versions of Java always seems to have such great features that people can’t resist fast tracking their upgrade path. The last time such features were introduced was probably Java 5 with generics and to a lesser degree annotations.

One such feature of Java 8 is lambda expressions which provide more than just syntactic sugar for closures. It provides somewhat automatic support for concurrent execution which in the days of Moore’s Law reaching its limits will be a boon for developers looking to multi-threaded programming for performance improvements.

While developer adoption of Java 8 will lead to more Java 8 deployments at the server level, one can also hope that this adoption might also leak out among the general public. Java 8 also has a rebooting of JavaFX and more installations out there might make Java FX more attractive on the desktop if more people are likely to be running a java installation that supports it.

Either way, its exciting times ahead for Java!

Fading in Primefaces Components

I was trying to fade in a Primefaces panel component that was initially hidden and found it to be somewhat of a struggle. After a bit of googling, the only thing I found out was that I wasn’t the first to come across the problem. Here’s the basic JSF code to use an effect on a panel in response to the button click.

<p:button id="showme" value="Show Me" onclick="return false">
	<p:effect type="fade" event="click" for="myPanel"/>
</p:button>

<h:panelGroup layout="block" id="myPanel" style="display:none">Show Me</h:panelGroup>

This code does nothing because by default the fade effect fades out the component. Looking at the options for the fade gives us no clues either since it claims there are no parameters. The solution is to provide a mode parameter that can be either show or hide which is used for most of the effects. In our case, we want to show the component.

<p:button id="showme" value="Show Me" onclick="return false">
	<p:effect type="fade" event="click" for="myPanel">
		<f:param name="mode" value="'show'"/>
	</p:effect>
</p:button>

<h:panelGroup layout="block" id="myPanel" style="display:none">Show Me</h:panelGroup>

This will show the panel that was initially hidden when you click the button. The only nagging problem is that the button retains its hover style until you click elsewhere in the page.