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!

    Back Home

    Its been 2 years since I last posted and a a lot of water has passed under the bridge since then. I’ve started a cub scout pack, coached under 8s soccer for a year, and spent 8 months on various DIY projects including renovating 3 bathrooms, a laundry room and kitchen ceiling, and 2 months selling my house. After all that I have finally moved back to Manchester in the UK which is where I am from originally.

    Now that things have quietened down a bit, I’m going to start looking at writing some more posts. Technology-wise, I’ve been mainly going where my work has taken me, which has mostly been Spring, some EJB, JSF and GWT. Future blog posts are more likely to be technology agnostic, but there will be posts dealing with specific technologies and how-tos.

    I personally enjoy reading longer and more in-depth posts or articles, and in general I enjoy writing them, but writing, proof-reading and re-reading takes a lot of time. As I only have a few hours to spend on non-work projects, I’m hopefully going to try and reach a balance with shorter posts more frequently (although brevity is often not in my nature).