QuickBytes


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)

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.

More Time Saved By Unit Tests

So I’ve been meaning to make a fix in one of my projects for a while, and I haven’t touched the code in over a year, so of course I have to go back and really get back up to speed with the code. The change was for the Datavalve project and it was to include support for passing in collections and using in SQL Statements, so now you can use something like :

provider.addRestriction("item.statusCode in (:param)", stateCodeList);

This will cause the list of codes to be expanded into an in SQL statement including checking to exclude null items, and as usual, the restriction is not included if the code list is null or contains only null items.

So I have two problems, the first is getting back up to speed on my code, figuring out where the make the change, and making it. The second is making sure my code changes don’t break anything thats currently working.

For the first problem, I decide to create the unit tests first so I can verify that the change does as expected. Obviously, the tests fail initially, but by looking at the code executed by the tests, I can start to pick out places where I need to start looking to add the new code. After all, tests measure the correctness of the state after the code has been executed. What better place to start looking than seeing what code the test executes. After finding the method that I need to change, I make my code changes and run my tests. All my original tests pass with flying colors, but my new test fails. I take a peek and sure enough I left off the last line of code to add the built object to a list. I put it in, and I have all my tests up and running.

All in all, I’ve made a large change to some sizable (12K+ LOC) code that I haven’t seen in over a year, verified that the change works and that it hasn’t impacted any other code. Not bad for an hour.

Update

I haven’t been writing for a while since I’ve been busy working on several things right now.

First off, after a few months of job hunting, I’ve changed jobs, I’m now doing some Java contract work down in Pittsburgh. After 11 years at my old job, it was time to move on. The great thing about contract work is the opportunity to work on a lot of different projects in a lot of different places. After being stuck in Cleveland for 11 years, we are ready for some changes.

I also want to try and get into doing some more Java EE 6 and CDI training. A lot of people are unsure of how it is all meant to work together and are missing out on the real beauty and simplicity of working with these frameworks.

Rick, Rob and I have been doing some more work with CDISource and anticipate a release of our source in the next few weeks. Once thats out, I want to start playing with some of the Seam 3 stuff especially with regards to CDI. We announced CDISource and then all of a sudden we all got busy with different things, and we have some code we want to release for which we have a number of articles to write.

Between moving, unpacking, starting a new gig, which always fries the brain for a few weeks, and having my Mum over from Manchester,England, I haven’t really been having time to write or work on projects.

I have a new release of the Knappsack almost ready to go which includes Spring based archetypes and also a Java EE 6 EAR archetype as well as a couple of new posts.

Google is just looking out for the folks

I noticed this little nugget in the Google Analytics FAQ :

Due to user privacy concerns, Google Analytics doesn’t report on personally identifiable information, including a visitor’s IP address.

Is this the same Google that will take a picture of you in your own home from 20 feet away, post it online, and tell you if you don’t want to be photographed in a certain manner you shouldn’t be doing it visibly in “public” ? This is in spite of the fact that I already have access to the IP addresses that visit the site.

Of course the real kicker is that they say they don’t report on such information, it doesn’t say they don’t capture it and use it for their own nefarious ends.

JBoss Java EE 6 spec dependency in Maven

Adam Bien wrote about the Troubled with the crippled Java EE 6 APIs in Maven and a solution for them. Another solution has presented itself now that JBoss has finalized the Java EE 6 spec pom and added it to their public repositories as of early January 2011.

You can include the spec in your own project by adding the following to your pom.xml :

<dependency>
	<groupId>org.jboss.spec</groupId>
	<artifactId>jboss-javaee-6.0</artifactId>
	<version>1.0.0.Final</version>
	<type>pom</type>
</dependency>

You may also need to add the JBoss repository to your pom.xml which is defined as :

<repositories>
	<repository>
		<id>repository.jboss.org</id>
		<name>JBoss Repository</name>
		<url>http://repository.jboss.org/nexus/content/groups/public-jboss/</url>
	</repository>
</repositories>

I’ll be adding this pom to the Knappsack archetypes to resolve some of the issues people have been facing with the broken spec dependency.

Read All About It!

I dusted off my PHP skills and added a new custom wordpress page to list all articles for a set of tags to create a kind of index page. The articles are grouped by tag and ordered by date so you can see the whole library of articles and tutorials. You can also find the index linkin the list of links in the header.

JBoss 6.0 CR1 is Released

JBoss has put out a CR1 release for JBoss 6.0 which implements the Java EE 6 specification. I don’t normally cover product releases, but I thought I may as well mention it since nobody else has (not even their blog). I only found out when I was sniffing around in their Maven Repositories and found the CR1 version of things. You download the latest from the JBoss download site.

CDI @Alternative Info

The @Alternative CDI annotation allows you to have multiple matching dependencies for a given injection point. This means you can define beans that provide implementations for the same interface without worrying about ambigious dependency errors. When you mark a class with the @Alternative annotation, it is effectively disabled and cannot be considered for injection. The only exception is for the class that is defined in the beans.xml configuration file.

<alternatives>
	<class>org.company.project.bean.SomeBean</class>
</alternatives>

Once this bean is identified, it is then used in any injection point that matches for this bean. No other beans for similar injection points can be declared as the ‘active’ alternative.

Alternative is really an odd name for it, but all it does is disable the bean while adding it to the beans.xml file enables it and makes it available to CDI.