Java


Java Patterns For Concurrency

This post talks about some of the patterns we can use to solve concurrency issues relating to state shared across multiple threads. The goal is to provide some smarter alternatives to slapping synchronized on every method call, or around every block of code. The problem with synchronized is that is requires everyone to participate. If you have an object that is mutable and it is shared by synchronizing on it, then nearly every use of that object will require a synchronized block and it only takes one person to forget to create bedlam. In general, the goal is to write code such that we don’t need to consider concurrency, and we can write code without concerning ourselves with how everyone else it handling concurrency.
Read More »

Java Concurrency – Introduction

This post is the first in a series on concurrency and describes the benefits and some of the problems with concurrency we might face in our code and simple ways we can fix them. While there are far more complex problems that require more advanced solutions they all share the same principles and in many cases, are rooted in these basic solutions. Read More »

Back from the Upside Down

I have been absent from my blog for a while, nearly 3 years to be precise, which coincides with starting my current job at an energy start-Up. There has been a lot of interesting work going on, during which we have won numerous awards, but last December, we secured round A funding of £6 million. Having achieved that goal it is time to take stock of a few things and make a few changes. Read More »

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 »