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 moved three times to two different US states, changed jobs, 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).

    Growing up a programmer in the 80s

    Despite the fact that there are plenty of free languages and development tools available online, there is still a much larger barrier to entry for someone who wants to get started as a programmer compared to nearly 30 years ago. I have fond memories of the computing of the 80s so I thought I’d take a quick trip down memory lane and write about my personal exerience of becoming a programmer. It may also be of interest to those familiar only with the Silicon Valley version of the history of computing since this covers events from the other side of the pond in the UK. When historians talk about the history of computing, they really only cover things like the TRS80, Altair and rise of the PC and Mac, yet there were many important and competitive developments in Europe that are often not included as part of this history.

    Read More »

    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"/>
    <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'"/>
    <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.