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 »

    AWS Builders Day 2018 – Manchester

    Last Tuesday I went to the AWS Builders Day here in Manchester at the Victoria Warehouse in Salford Quays. Like most of the country, we woke up to snow on the ground which is pretty rare here in the UK. Having lived in Cleveland, Ohio in the US for 15 years, I am not unaccustomed to getting 3 foot of snow this time of year so the inch or two we got wasn’t putting me off. On the plus side, not too many people travelling the Metrolink Tram, but on the bad side, the trams were only running to MediaCity which meant a 20-minute walk to the Victoria Warehouse. Despite the weather, I was able to get there in plenty of time and was met with free coffee and pastries. 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.