Archive | June 2013

Implementing a custom JSF 2.0 component with maven

Some time ago, I have written my own custom JSF component. But at that point in time, JSF 1.0 was still up to date and the project didn’t use maven as build system. Thus, I always wanted to write a custom JSF2 component with maven. So let’s start:

First of all we setup a maven project with two modules. Here is the pom.xml file of the parent project:

<project xmlns="" xmlns:xsi=""
	<name>jsf-component Maven Webapp</name>

As you can see, we have added the JSF dependencies in the top level pom.xml, so that we inherit them in the child modules. As we will use the JBoss Application Server to test our web application, we have to set the scope for the maven dependencies to provided, so that our war file and our component jar won’t deploy them.
The implementation of our component will reside in jsf-component-impl, thus we chose jar as packaging type for this module:

<?xml version="1.0"?>
	xmlns="" xmlns:xsi="">

Now let’s implement a Java class that extends UIOutput. I have chosen UIOutput because as a first step I just want to implement a simple helloWorld tag, that prints the first and last name given as attribute within a span element. As this component doesn’t receive any input, UIOutput it appropriate:



import javax.faces.application.ResourceDependencies;
import javax.faces.application.ResourceDependency;
import javax.faces.component.FacesComponent;
import javax.faces.component.UIOutput;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;

@ResourceDependencies({ @ResourceDependency(name = "css/jsf-component.css", target = "head") })
public class HelloWorldComponent extends UIOutput {
	private static final String COMPONENT_FAMILY = "";

	private enum PropertyKeys {
		firstName, lastName

	public String getFamily() {

	public void encodeBegin(FacesContext context) throws IOException {
		ResponseWriter writer = context.getResponseWriter();
		writer.startElement("span", this);
		writer.writeAttribute("class", "helloWorldClass", "");
		writer.writeText(String.format("Hello %s %s!", getFirstName(), getLastName()), "");

	public String getFirstName() {
		return (String) getStateHelper().eval(PropertyKeys.firstName, "???firstName???");

	public void setFirstName(String firstName) {
		getStateHelper().put(PropertyKeys.firstName, firstName);

	public String getLastName() {
		return (String) getStateHelper().eval(PropertyKeys.lastName, "???lastName???");

	public void setLastName(String lastName) {
		getStateHelper().put(PropertyKeys.lastName, lastName);

The getFamily() method is the only method that we are enforced to implement. Interesting is here the method encodeBegin(). This is the place where we implement our span tag. As it should have a CSS class attribute, we add it with the writeAttribute() method of the Writer. The two attributes of the resulting JSF tag are modelled as simple properties with getter and setter methods. The implementation of these getters and setters uses the StateHelper available in JSF 2.0. In encodeBegin() we use the getters to retrieve the value given by the user.
Interesting is also the annotation @ResourceDependencies. With this annotation we can tell the JSF framework that we have some files we depend on. In this case it is a CSS file that resides with the folder src/main/resources/META-INF/resources/css.
The annotation @FacesComponent registers this component in the boot process at the JSF framework. The given name is used in the taglib file to reference this class:

<?xml version="1.0"?>
<facelet-taglib xmlns="">

In this taglib file under src/main/resources/META-INF we define the available components, here only our helloWorld tag. The attributes of the tag are derived from the properties of the Java class.
Finally we want to test our newly created component. To be able to do this, we setup a simple JSF2 webapp project and add the following snippet to the web.xml, in order to declare that we want to use our custom component:


Now we can write a simple JSF page that references our new tag:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns=""
<title>Hello JSF 2!</title>
	<h2>Hello World!</h2>
	<mdw:helloWorld firstName="Martin" lastName="Developer"/>

When we deploy this application to the JBoss Application Server and call the corresponding URL, we get the following HTML output:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="">
	<title>Hello JSF 2!</title>
	<link type="text/css" rel="stylesheet" href="/jsf-component-webapp/faces/javax.faces.resource/css/jsf-component.css" />
	<h2>Hello World!</h2>
	<span class="helloWorldClass">Hello Martin Developer!</span>

Clearly we can see the span tag with the CSS class and the output. The CSS file is referenced in the head of the HTML document.

The sources of the whole project can be found on GitHub:

Benchmarking the famous refactoring of GeneratePrimes in Robert C. Martin’s ‘Clean Code’

Inspired by Tomasz Nurkiewicz’ blog post about how aggressive the inlining capability of the Java Virtual Machine is (original blog post), I asked myself what impact the refactorings to the famous GeneratePrimes class in Robert C. Martin’s book ‘Clean Code’ (see page 71) are. Therefore I set up a small benchmark project that can be found here on GitHub:

Under src/main/java you will find the two classes as they are published in the book and under src/test/java a unit test that runs the generatePrimes() method of the two classes with different values for the argument maxValue, ranging from 10 to The unit test prints out the measured time in milliseconds like this:

OneMethod : 1083,00 ms for 10
PlentyMethods: 490,17 ms for 10
OneMethod/PlentyMethods: 2,21 (< 1 means OneMethod is faster)
OneMethod : 12,40 ms for 100
PlentyMethods: 19,68 ms for 100
OneMethod/PlentyMethods: 0,63 (< 1 means OneMethod is faster)
OneMethod : 125,75 ms for 1000
PlentyMethods: 179,22 ms for 1000
OneMethod/PlentyMethods: 0,70 (< 1 means OneMethod is faster)
OneMethod : 1386,68 ms for 10000
PlentyMethods: 2069,76 ms for 10000
OneMethod/PlentyMethods: 0,67 (< 1 means OneMethod is faster)
OneMethod : 10096,85 ms for 100000
PlentyMethods: 10365,03 ms for 100000
OneMethod/PlentyMethods: 0,97 (< 1 means OneMethod is faster)
OneMethod : 26232,72 ms for 1000000
PlentyMethods: 8215,29 ms for 1000000
OneMethod/PlentyMethods: 3,19 (< 1 means OneMethod is faster)
OneMethod : 184577,74 ms for 10000000
PlentyMethods: 184149,59 ms for 10000000
OneMethod/PlentyMethods: 1,00 (< 1 means OneMethod is faster)
OneMethod : 2100707,11 ms for 100000000
PlentyMethods: 2103006,56 ms for 100000000
OneMethod/PlentyMethods: 1,00 (< 1 means OneMethod is faster)

The logging statement beginning with OneMethod is the old-styled implementation which computes all prime numbers up to the given maximum value with only one method, whereas the statement beginning with PlentyMethods uses the refactored version using plenty methods for the implementation of the same algorithm. As you will notice, the difference between both implementations converges against 1.00. This means that after some time all private methods of the refactored implementation have been inlined and do not cause any runtime overhead. Until 100.000 the one method implementation is faster, afterwards (interestingly except for the 1.000.000 measurement) the difference in runtime is 1. Surprisingly the first measurement shows up that the plenty method implementation is even faster than the old-styled implementation.

PS: The measurement were taken on the following setup: Intel Core i5, 2.4 GHz, 4GB RAM, 64Bit; Windows 7, Java(TM) SE Runtime Environment (build 1.7.0_21-b11).