package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
 
import java.sql.Timestamp;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.lang.time.DateUtils;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TransactionConfiguration(defaultRollback=false)
public class HibernateDateTimeTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	private Session currentSession;
 
	private Date birthDateWithTime;
	private Date birthDateWithoutTime;
	private Date createDate;
	private Date modifyDate;
 
	@Before
	public void setUp() throws Exception{
		currentSession = sessionFactory.getCurrentSession();
		birthDateWithTime = new Date();
		birthDateWithoutTime = DateUtils.truncate(birthDateWithTime, Calendar.DATE);
		createDate = new Date();
		modifyDate = new Date();
	}
 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                      birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}
 
	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}
 
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
}

Here is the mapping for person.

...
@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="timestamp")
	private Date createDate;
 
	@Column
	private Date modifyDate;
	...
}

There are three Date fields: ‘birthdate’, ‘createDate’, and ‘modifyDate’. The fields ‘birthDate’ and ‘createDate’ have a specified Type. The field ‘modifyDate’ however, does not have a specified Type. The generated SQL from Hibernate is as follows.

CREATE TABLE Person (id bigint generated BY DEFAULT AS identity (start WITH 1), 
birthDate date, createDate timestamp, firstName varchar(255), 
lastName varchar(255), modifyDate timestamp, PRIMARY KEY (id))

We see that Hibernate created ‘birthDate’ as a ‘Date’ and the other two were created as a ‘Timestamp’. The primary difference between ‘Date’ and ‘Timestamp’ in SQL is that ‘Timestamp’ holds the date and time while the ‘Date’ only holds the date.

At first glance this is not a big deal, but let’s take a closer look at the test.

 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                           birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}

Person is created with three Dates that all include date and time values.

	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}

When Hibernate retrieves a Person from the database the ‘createDate’ and ‘modifyDate’ have been converted to Timestamps. At first glance this doesn’t appear to be a big deal. java.sql.Timestamp extends java.util.Date. But why are they not equal. I found a helpful answer to this question in Effective Java (2nd Edition) page 41.

There are some classes in the Java platform libraries that do extend an instantiable
class and add a value component. For example, java.sql.Timestamp
extends java.util.Date and adds a nanoseconds field. The equals implementation
for Timestamp does violate symmetry and can cause erratic behavior if
Timestamp and Date objects are used in the same collection or are otherwise intermixed.
The Timestamp class has a disclaimer cautioning programmers against
mixing dates and timestamps. While you won’t get into trouble as long as you
keep them separate, there’s nothing to prevent you from mixing them, and the
resulting errors can be hard to debug. This behavior of the Timestamp class was a
mistake and should not be emulated. (Bloch, Effective Java, 2nd Ed.)

If you want to read more about ‘equals’ read chapter 3, Item 8 in Effective Java (2nd Edition). Apart from a hack there are two primary ways to solve this issue. The first way involves typing ‘createDate’ and ‘modifyDate’ to Timestamp.

	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	private Timestamp createDate;
 
	@Column
	private Timestamp modifyDate;
        ...

The second approach uses a custom UserType. Here is a custom UserType that converts Timestamp to Date and vise versa. There is a side effect with this solution. Converting Timestamp to Date drops the nanosecond precision. If this is not acceptable then the previous solution should be used.

package com.sourceallies;
 
import java.io.Serializable;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.sql.Types;
import java.util.Date;
 
import org.hibernate.HibernateException;
import org.hibernate.usertype.UserType;
 
public class DateTimeUserType  implements UserType {
 
	@Override
	public int[] sqlTypes() {
		 return new int[]{Types.TIMESTAMP};
	}
 
	@SuppressWarnings("rawtypes")
	@Override
	public Class returnedClass() {
		return Date.class;
	}
 
	@Override
	public boolean equals(Object x, Object y) throws HibernateException {
		 return x == y || !(x == null || y == null) && x.equals(y);
	}
 
	@Override
	public int hashCode(Object x) throws HibernateException {
		return x.hashCode();
	}
 
	@Override
	public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
			throws HibernateException, SQLException {
		Timestamp timestamp = rs.getTimestamp(names[0]);
        if (rs.wasNull()) {
            return null;
        }
        return new Date(timestamp.getTime());
	}
 
	@Override
	public void nullSafeSet(PreparedStatement st, Object value, int index)
			throws HibernateException, SQLException {
        if (value == null) {
            st.setNull(index, Types.TIMESTAMP);
        }
        else {
            Date date = (Date) value;
            Timestamp timestamp = new Timestamp(date.getTime());
            st.setTimestamp(index, timestamp);
        }
	}
 
	@Override
	public Object deepCopy(Object value) throws HibernateException {
		return value;
	}
 
	@Override
	public boolean isMutable() {
		return false;
	}
 
	@Override
	public Serializable disassemble(Object value) throws HibernateException {
		 return (Serializable) value;
	}
 
	@Override
	public Object assemble(Serializable cached, Object owner)
			throws HibernateException {
		return cached;
	}
 
	@Override
	public Object replace(Object original, Object target, Object owner)
			throws HibernateException {
		return original;
	}
}

Here is the way to use it in the Person class.

@Entity
@TypeDefs({
		@TypeDef(name="dateTimeUserType", typeClass=DateTimeUserType.class)
})
public class Person {
	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date createDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date modifyDate;
        ...

Either of these solutions will prevent the ‘equals’ issue that we encountered before. This issue is not a Hibernate issue it is truly a Java issue as is stated in Effective Java (2nd Edition). Hibernate can be challenging enough without these subtle issues that are easy to miss until a bug is reported.

Here is the complete code. Hibernate Logging Zip .

In this article I will show you how to add a simple logger to Hibernate.

Start with a Test

As an avid TDD practitioner I will of coarse start with a test. Here is the final version of the test that I used to drive my code.

package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
 
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.logging.Log;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class HibernateInterceptorTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	@Resource
	private HibernateInterceptor hibernateInterceptor;
 
	private Session currentSession;
 
	private Log logger;
 
	private static final Date NOW = new Date();
 
	@Before
	public void setUp(){
		logger = mock(Log.class);
		currentSession = sessionFactory.getCurrentSession();
		hibernateInterceptor.setLogger(logger);
	}
 
	@Test
	@Transactional
	public void testSaveLogging(){
		saveOrUpdate(createPerson());
 
		assertEquals(1, findAll().size());
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testUpdateLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
		firstPerson.setFirstName("testFirst2");
 
		saveOrUpdate(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Updating Person [firstName=testFirst2, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testDeleteLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
 
		delete(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Deleting Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Transactional
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@Transactional
	public void delete(Person person) {
		currentSession.delete(person);
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
 
 
	private Person createPerson() {
		Person person = new Person("testFirst", "testLast", NOW);
		return person;
	}
}

I used a mock logger to gather information from the interceptor.

Spring Configuration

Here is the configuration required for the interceptor.

 
	<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
                ...
		<property name="dataSource" ref="dataSource" />
		<property name="entityInterceptor" ref="hibernateInterceptor"/>
	</bean>
 
	<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
		<property name="sessionFactory" ref="sessionFactory" />
	</bean>
         ...	
	<context:component-scan base-package="com.sourceallies" />
        ...

The ‘entityInterceptor’ property on the ’sessionFactory’ takes a Hibernate interceptor.

Entity

@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	private Date birthDate;
...
	@Override
	public String toString() {
		return "Person [firstName=" + firstName + ", lastName="
				+ lastName + ", birthDate=" + birthDate + "]";
	}
}

For this example you need to implement the ‘toString’ method on the entity being logged.

Interceptor

Here is the interceptor code.

package com.sourceallies.logging;
 
import java.io.Serializable;
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.hibernate.EmptyInterceptor;
import org.hibernate.type.Type;
import org.springframework.stereotype.Component;
 
@Component
public class HibernateInterceptor extends EmptyInterceptor {
 
	private static final long serialVersionUID = 1L;
	private Log logger = LogFactory.getLog(HibernateInterceptor.class);
 
	@Override
	public void onDelete(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Deleting", id, entity);
		super.onDelete(entity, id, state, propertyNames, types);
	}
 
	@Override
	public boolean onFlushDirty(Object entity, Serializable id,
			Object[] currentState, Object[] previousState,
			String[] propertyNames, Type[] types) {
		log("Updating", id, entity);
		return super.onFlushDirty(entity, id, currentState, previousState,
				propertyNames, types);
	}
 
	@Override
	public boolean onSave(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Saving", id, entity);
		return super.onSave(entity, id, state, propertyNames, types);
	}
 
	protected void setLogger(Log logger) {
		this.logger = logger;
	}
 
	private void log(String action, Serializable id, Object entity) {
		logger.info(action + " " + entity + ".");
	}
}

While the ‘onSave’ and ‘onDelete’ methods are clearly named the ‘onUpdate’ method appears to be missing. With a little research it quickly becomes obvious that ‘onFlushDirty’ is used for updates.

Logging database activity is this simple.

Here is the complete code. Hibernate Logging Zip

If your team spends more than an afternoon deploying their product to a test region or to production then you need to start chipping away at this next step. Agile software development emphasizes working software. While this seems like a no-brainer, we often neglect the core issues that prevent our software from working. The most significant one being that we often do not know our software does not work until it is too late.

The single most powerful change that you can bring to your software development team is continuous deployment. What does this mean? I’m not suggesting that you auto deploy to production. I have not worked with an organization yet that is ready to make this leap of faith. Instead I’m encouraging you to:

1. automate your deployment process and run it every time your check in your code.
2. run a couple of user tests that walk through the most common end-to-end flows

While this may seem fairly straight forward this is difficult to complete. Much of this depends on your architecture, infrastructure and policies. To illustrate this point let’s look at a project that I lead a couple of years ago. In order to auto deploy our project and run test against our product we needed:

1. to have admin privileges on 5 dedicated database.
2. to create the database from versioned scripts
3. to load test data in each database
4. to have an application server on our CI box.
5. to have a message queue on our CI box.
6. to have three web services deployed and running
7. to have a build process that can automatically build and deploy an EAR to the application server

Policies, licensing and time are the largest barrier standing in the way of achieving this in any organization. This example may be more or less complex than the needs on your project. Nevertheless, in my experience working to break down these barriers is essential to delivering working software. Being able to address deployment issues as they come up is much less stressful than standing in a cube after hours trying to figure out why this stupid app won’t work with managers asking if you are “done yet”.

Policies can be changed if you track the amount of wasted time as it relates to deployment delays. Licensing costs can be accounted for or avoided (open source) if managers understand the savings. And as far as time goes, I’m more willing to put some time up front so I don’t have to loose my nights and weekends at the end of the project.

I know that this is possible. I have seen it work on numerous projects and team. Take the next step in Agility and automate your deployment process. Ensure that your software works by running a few end-to-end user tests. The effort is worth it. Your time and sanity is worth it.

Paradigm Shift

When I entered the development scene I was immersed in Object Oriented programming. As a result, I tend to think of good design in objects. A few years ago I began to learn and apply Groovy. With closures I was able to bleed into the realm of Functional programming. This gave me a small taste of a new paradigm. I thought of new ways to solve problems that I couldn’t see with Java. I can only imagine how much more I could learn if I developed exclusively in a Functional language for several months.

I tend to see two camps when it comes to learning new languages. The first camp thinks that the language that they know is sufficient for solving all programming problems. The second camp runs after the newest hot thing and divorces themselves from their old language. Neither extreme is healthy. We need to see languages as tools. A hammer is not good for solving all problems. Sure you might be able to turn a screw with the claw of a hammer but why would you. We need to understand our problems first and select a language that solves it best.

JVM languages allow us to make this decision at the last responsible moment. We can select a JVM language that seems appropriate and begin coding. If it becomes clear later that this language is not well suited to solve this problem then we can change our mind. The JVM provides a single platform for us to use the best tool for the job. We can even use multiple languages to develop one system. The JVM is an amazing canvas for agility.

Detour

Now I want to take what may seem like a major detour. However I would suggest that this does not stray all that far. We need to extend our effort to become multilingual beyond the JVM. As professionals we would benefit from learning the language of different business areas. Management, Testers, and Business Analysts solve problems in different language paradigms.

Many developers begin to tune out as I mention management. Feelings of frustration begin to take over. We can tolerate BA’s and Testers for the most part but management is just a waste of time. The pain and frustration from the past takes over and we just tune out. We code in secret and try not to disturb the gods of management. We avoid them and hopefully they will leave us alone.

While I’m not here to say that all management is just massively misunderstood and we need to forgive and forget, we do need to learn to communicate. We often contribute to our own misery. We are either silent or we speak in a language that makes no sense. We need to learn their language.

Speaking the Same Language

Before I proceed let me make a very important side note. Not all managers are open to an intelligent and rational discussions. Some have given in to money and power and they just want to be right no matter the cost. While this can be true, I think that there are many managers that can be reasonable. The challenge is not intellectual but one of language.

How do managers think? Well one simple way to find out is to listen to them. What are they focused on? What excites them? What frustrates them? But the most important question is why. Why are they focused on certain things? The question of why delves into the area of motivation. What motivates management? Sure we can go for the easy answer of money, but is that the whole story?

Expanding our Library

Once you start listening I believe we need to move to education. We need to add a few business books to our technical library. Begin to understand the information that managers are focused on. Take time to understand how they get information and how that effects their decisions. And now it’s time for a big leap. How can we provide information from our development effort that can influence management decisions. Now I want to caution you. This will not always work. But if we are not speaking manager-eez then we can not expect to influence their decisions. I see this same challenge in my marriage. My wife doesn’t focus on the same things that I do. Nevertheless, over time we’ve learned to speak each others language. We work to bridge this divide because we “care” about each other. I know I brought out a feeling word. We can try to avoid the “F” word, but if we don’t care enough to take the first step to bridge the technical and management divide who will?

Balancing Act

Once you have a good understanding of how your management team makes decisions, you need to get the right information to them. While every company and manager is different there tend to be some common ingredients in their decision making process. The first ingredient is return on investment (ROI). The second ingredient is generally risk management.

As a developer these tend to make me irritated. ROI appears to be something that can not be accurately measured and risk management just results in more work. However these are things that we deal with in our personal lives all the time. Marriage, 401K, children, cars, investments, homes all require us to consider ROI and risk. After buying three homes and selling two I am painfully aware of ROI and the need for risk assessment. Each purchase has different factors. A starter home needs to be something that I can resell in a few years. However starter homes often require a lot of maintenance and updating. A retirement home needs to be built to last. Similarly, every management decision has specific factors that drive the decision.

In software development the major factors tend to be: time-to-market, timeliness, development cost, maintenance costs, usability, scalability, security and features. The right product at the wrong time results in a useless product. A great 8 track player delivered in 1980 as the cassette tape market was on the rise, would be a waste of money. If you were one of the 70 million customers of Sony’s PlayStation that had their information stolen this year, all the other features became less important. Developing software, or products, is not just a matter of putting the correct components together. Good managers try to balance all the moving parts.

Show me the Facts

So how can we provide valuable information? One vital piece of information is the project burndown. A burndown projects the projected completion date based on the historical velocity and the size of the feature backlog. But marching towards the finish line does not always equate to a valuable product. Regular demos to the customer allows us to calibrate the relevance and usability. Tracking the feedback from these demos helps us measure the value of the current product.

Another factor to measure is the maintainability of a product. As we set a development pace we need to determine if this pace is creating waste. Managers have to weigh the cost of speedy development with the cost of long-term maintenance. But without any data this decision can not be made. Are developers just wasting time trying to make a Rolls-Royce when we just need a Pinto? We need facts not opinions to steer the ship of management. Instead of pretending that I am an expert in this area I am going to recommend that you read two of Neal Ford’s articles on “Evolutionary architecture and emergent design”.

• Evolutionary architecture and emergent design: Environmental considerations for design, Part 1
• Evolutionary architecture and emergent design: Emergent design through metrics

While the topic may be a little different from this blog these articles contain amazing insight on gathering, analyzing and visualizing technical debt. Technical debt is that elusive beast that we feed when we, with the best intentions, just try to “get-er done”. The fatter this beast gets the harder it is to make changes during the development process and during long-term maintenance. In this case harder means more costly.

Summary

As developers we are focused on language. We use words to create software. We translate business words into code. We are in fact professional interpreters. We use our multilingual skills to translate concepts into working software. But when it comes to bridging the communication divide between software development and management decisions we often give up. We try to use emotion pleas or technical words to effect change but people quickly stop listening.

As professional, multilingual, translators we need to focus our skills on effectively communicating with management. We need to understand their domain and gather valuable and relevant information that can guide their decisions. Instead of avoiding management we need to engage them. We need to gather information that only we poses and translate it into information that makes sense to critical decision makers. We need to become part of the solution instead of contributing to an overwhelming problem.

I’ve been asked several times to explain the difference between injecting Spring beans with ‘@Resource’, ‘@Autowired’, and ‘@Inject’. While I received a few opinions from colleagues and read a couple of posts on this topic I didn’t feel like I had a complete picture.

Annotations

In order to explore the behavior of each annotation I fired up Spring Tool Suite and started debugging the code. I used Spring 3.0.5.RELEASE in my research. The following is a summary of my findings.

The Code

I wanted to know how ‘@Resource’, ‘@Autowired’, and ‘@Inject’ resolved dependencies. I created an interface called ‘Party’ and created two implementations classes. This allowed me to inject beans without using the concrete type. This provided the flexibility I needed to determine how Spring resolves beans when there are multiple type matches.

public interface Party {
 
}

‘Person’ is a component and it implements ‘Party’.

package com.sourceallies.person;
...
@Component
public class Person implements Party {
 
}

‘Organization’ is a component and it implements ‘Party’.

package com.sourceallies.organization;
...
@Component
public class Organization implements Party {
 
}

I setup a Spring context that scans both of these packages for beans marked with ‘@Component’.

<context:component-scan base-package="com.sourceallies.organization"/>
<context:component-scan base-package="com.sourceallies.person"/>

Tests

Test 1: Ambiguous Beans

In this test I injected a ‘Party’ bean that has multiple implementations in the Spring context.

@Resource
private Party party;

@Autowired
private Party party;

@Inject
private Party party;

In all three cases a ‘NoSuchBeanDefinitionException’ is thrown. While this exception’s name implies that no beans were found, the message explains that two beans were found. All of these annotations result in the same exception.

org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No unique bean of type [com.sourceallies.Party] is defined: 
expected single matching bean but found 2: [organization, person]

Test 2: Field Name

In this test I named the Party field person. By default beans marked with ‘@Component’ will have the same name as the class. Therefore the name of the class ‘Person’ is person.

@Resource
private Party person;

@Autowired
private Party person;

@Inject
private Party person;

‘@Resource’ can also take an optional ‘name’ attribute. This is equivalent to the ‘@Resource’ code above. In this case the field variable name remains ‘party’. There is no equivalent syntax for ‘@Autowired’ or ‘@Inject’. Instead you would have to use a ‘@Qualifier’. This syntax will be covered later.

@Resource(name="person")
private Party party;

All four of these styles inject the ‘Person’ bean.

Test 3: Field Type

In this test I changed the type to be a ‘Person’.

@Resource
private Person party;

@Autowired
private Person party;

@Inject
private Person party;

All of these annotations inject the ‘Person’ bean.

Test 4: Default Name Qualifier

In this test I use a ‘@Qualifier’ annotation to point to the default name of the ‘Person’ component.

@Resource
@Qualifier("person")
private Party party;

@Autowired
@Qualifier("person")
private Party party;

@Inject
@Qualifier("person")
private Party party;

All of these annotations inject the ‘Person’ bean.

Test 5: Qualified Name

I added a ‘@Qualifier’ annotation to the ‘Person’ class

package com.sourceallies.person;
...
@Component
@Qualifier("personBean")
public class Person implements Party {
 
}

In this test I use a ‘@Qualifier’ annotation to point to the qualified name of the ‘Person’ component.

@Resource
@Qualifier("personBean")
private Party party;

@Autowired
@Qualifier("personBean")
private Party party;

@Inject
@Qualifier("personBean")
private Party party;

All of these annotations inject the ‘Person’ bean.

Test 6: List of Beans

In this test I inject a list of beans.

@Resource
private List<Party> parties;

@Autowired
private List<Party> parties;

@Inject
private List<Party> parties;

All of these annotations inject 2 beans into the list. This can also be accomplished with a ‘@Qualifier’. Each bean marked with a specific qualifier will be added to the list.

Test 7: Conflicting messages

In this test I add a bad ‘@Qualifier’ and a matching field name.

@Resource
@Qualifier("bad")
private Party person;

@Autowired
@Qualifier("bad")
private Party person;

@Inject
@Qualifier("bad")
private Party person;

In this case the field marked with ‘@Resource’ uses the field name and ignores the ‘@Qualifier’. As a result the ‘Person’ bean is injected.

However the ‘@Autowired’ and ‘@Inject’ field throw a ‘NoSuchBeanDefinitionException’ error because it can not find a bean that matches the ‘@Qualifier’.

 org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No matching bean of type [com.sourceallies.Party] found for dependency: 
expected at least 1 bean which qualifies as autowire candidate for this dependency. 
Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true),
@org.springframework.beans.factory.annotation.Qualifier(value=bad)}

Conclusions

With the exception of test 2 & 7 the configuration and outcomes were identical. When I looked under the hood I determined that the ‘@Autowired’ and ‘@Inject’ annotation behave identically. Both of these annotations use the ‘AutowiredAnnotationBeanPostProcessor’ to inject dependencies. ‘@Autowired’ and ‘@Inject’ can be used interchangeable to inject Spring beans. However the ‘@Resource’ annotation uses the ‘CommonAnnotationBeanPostProcessor’ to inject dependencies. Even though they use different post processor classes they all behave nearly identically. Below is a summary of their execution paths.

@Autowired and @Inject

1. Matches by Type
2. Restricts by Qualifiers
3. Matches by Name

@Resource

1. Matches by Name
2. Matches by Type
3. Restricts by Qualifiers (ignored if match is found by name)

While it could be argued that ‘@Resource’ will perform faster by name than ‘@Autowired’ and ‘@Inject’ it would be negligible. This isn’t a sufficient reason to favor one syntax over the others. I do however favor the ‘@Resource’ annotation for it’s concise notation style.

@Resource(name="person")

@Autowired
@Qualifier("person")

@Inject
@Qualifier("person")

You may argue that they can be equal concise if you use the field name to identify the bean name.

@Resource
private Party person;

@Autowired
private Party person;

@Inject
private Party person;

True enough, but what happens if you want to refactor your code? By simply renaming the field name you’re no longer referring to the same bean. I recommend the following practices when wiring beans with annotations.

Spring Annotation Style Best Practices

1. Explicitly name your component [@Component("beanName")]
2. Use ‘@Resource’ with the ‘name’ attribute [@Resource(name="beanName")]
3. Avoid ‘@Qualifier’ annotations unless you want to create a list of similar beans. For example you may want to mark a set of rules with a specific ‘@Qualifier’ annotation. This approach makes it simple to inject a group of rule classes into a list that can be used for processing data.
4. Scan specific packages for components [context:component-scan base-package="com.sourceallies.person"]. While this will result in more component-scan configurations it reduces the chance that you’ll add unnecessary components to your Spring context.

Following these guidelines will increase the readability and stability of your Spring annotation configurations.

Related Links

Testing Spring Wiring
Beanoh Spring Wiring Test Framework

First thing I did was to take a heap dump.

I selected the classes and I see

Well THAT was not helpful. It turns out that the leak is in a class that only has one instance and it is holding onto thousands of objects.
Then on the summary page I notice the “Find 20 biggest objects by retained size:”.

I click it and a long time later I see

Shazam! There it is! In this faked up example I built there is a single Stack instance but it’s retained size is huge. That because VisualVM computed not just the size of that object but the sizes of all of the objects it was holding onto. How sweet is that. I found my memory leak in like 5 minutes.

Another useful tool!

I’ve been using open source software for many years, but I’ve never open sourced my own project. This blog is a record of my experience as I start this journey. The resulting project can be found at http://beanoh.org.

Where

First I had to decide where to store the code.  There are several popular (Comparison of open source software hosting) open source hosting options. I chose GitHub (github.com) because I already had an account and I’m comfortable using Git.  Furthermore, GitHub provides intuitive tools that make it easy to manage a project.  I can setup an organization so multiple Source Allies employees can have commit rights on this project.  GitHub also has an integrated issue and feature tracking system that connects commits with tickets.  Overall I am very impressed with GitHub.

License

Before I push my code into GitHub I need to choose a liscense. This seems very overwhelming. I’m not a lawyer so how can I understand what each license provides? I started by searching for comparison charts. Out of these results I found the following comparisons helpful:

• Comparison of free software licenses
• Open Source License Comparison
• open source licenses for dummies

I feel like I understand the differences a little better, but I would like to know what other open source projects are using. I found a list of the “Top 20 Most Commonly Used Licenses in Open Source Projects” (http://www.blackducksoftware.com/oss/licenses). With the comparisons and the ranking I am leaning towards the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL).

I went to ‘gnu.org’ to research these licenses and I stumbled across a page called Why you shouldn’t use the Lesser GPL for your next library. It says, “The choice of license makes a big difference: using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.” In my mind this is a reason to use the “Lesser” license. I want to provide an open source project that can be used in any product. The “Lesser” license provides more to the community.  In all fairness it is worth mentioning that the ordinary GPL is designed to encourage developers to open source the software that uses these libraries. In my case I want to make my library available to anyone.

Now that I have decided on the license I am going to put the following disclaimer at the top of every file:

Copyright (c) 2011 Source Allies

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation;
version 3.0.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with this library; if not, visit
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt.

I also need to include a license.txt file at the root of my project that contains the full text of the LGPL.

Make sure you get the license in place before you start distributing or using the jar with third party organizations. In the case of consulting the client may end up owning the product if it is not licensed properly. Why go to so much trouble to open source code just to have the right lost to a third party organization?

Setup GitHub

I already have a GitHub account, but I want to setup an organization to manage a team of developers. I am able to create an organization under my personal ‘Account Settings’ under ‘Organizations’. I clicked the ‘Create Organization’ button and followed the wizard. For more information visit https://github.com/blog/674-introducing-organizations.

Collaboration

I am curious how open source projects manage changes from non-committers. I found a great article at GitHub that explains how most teams collaborate within their site (http://help.github.com/pull-requests). In short, contributors outside of the core development team submit “Pull Requests”. The project administrator(s) review these requests and decide if they want to merge them back into the code base. In my experience Git merging is fairly painless. This model allows anyone in the world the opportunity to contribute, while preserving the owners right to control the flow of changes. Too many chefs in the kitchen will ruin the food.

U-turn

I started looking for “How To” open source software articles and books. I didn’t find very many resources. Everyone talks about how to use open source, but very few people talk about how to effectively open source your own software. Eventually I ran accross “Producing Open Source Software: How to Run a Successful Free Software Project” by Karl Fogel (http://producingoss.com/producingoss.pdf). This book is a collection of insights from a major contributor to the open source project Subersion (http://subversion.apache.org).  I gravitated to this book because it is free.  Apparently Karl believes software and books should be available at no charge .

In the first chapter Fogel suggestes that 90 to 95% of all open source projects fail.  As the founding committer of Subversion, Karl has a little bit of experience leading a wildly successful open source project.  “This book is about avoiding failure. It examines not only how to do things right, but how to do them wrong, so you can recognize and correct problems early.” (p. 10)  So it is time to look at my mistakes so far.

First, I have not selected a “good name” (p. 21-22).  So what does “good” mean.  The project names that I talk about are the ones that I remember.  I am drawn to word plays like Mockito (mockito.org) which is a play on the drink Mojito.  When I heard it I remembered two things, the punny name and it’s purpose of mocking.

Second, I need to develop a “clear mission” (p. 22 – 23).  I have to admit that this idea of a mission statement is overwhelming to me.  In order to put myself to sleep I googled a few corporate mission statements.  Without referring back to their statements I would not be able to tell you what they were.  Ultimately they stated that they were super awesome organizations focused on making money.  Nevertheless, what is a good and useful mission statement?  Karl describes it as a “quick description”.  A statement that helps the customer decide in 30 seconds if they are interested in your project.  He recommends that this statement be “prominently placed on the front page, preferably right under the project’s name.” (p.22)  If we take a look at Mockito again they  state, right under their name, that it is “simpler & better mocking” (mockito.org).  Traditionally I would consider this a tagline and not a mission statement.  Nevertheless, I know several company’s taglines but I don’t know a single “mission statement”.  So what the heck, why split hairs?

While it seems strange, the third thing is to “state that the project is free”. (p. 22-23).  I had to visit several open source project homepages to find an example of this.  I did find the phrase “open source’ in the first two sentences at http://subversion.apache.org.  This does not seem to be a common practice, but it doesn’t take much effort to put the words “open source” in the description of the project.

Fourth, I need to take time to create clear documentation (p. 26-29).  This just takes time.  The obvious first step is a Getting Started page.   What’s more difficult is writing this from the perspective of someone that knows nothing about my product.  Fogel suggests that you do not have to wait until you have comprehensive documentation.  On the other hand, just write down some basic information.  It does not matter if it is incomplete.  Focus on helping new users get your product running.

New Direction

After reading this I need to slow down and make sure that we put our best foot forward.  We need a good name, logo, and well designed website.  I need to clearly state what this software does.   I need to put together some basic documentation that is easy to read and understand.

After some discussion we decided to setup a logo contest on https://99designs.com. This was very easy to setup and we got some amazing designs. I also went through every class and added javadocs. I put together some short screen casts with Camtasia (http://www.techsmith.com/camtasia/). This took a few tries, but the results were well worth it. Now I’m working on integrating all of this documentation into an intuitive and effective website design.

As a software developer it is easy for me to focus on the technical aspects of my software and neglect the presentation. While this may not be my initial focus I found that as a consumer I evaluate other projects in a few seconds based on how their websites looks. If I feel like it is interesting I start click through their site. If I don’t “get it” in a few clicks I move on. This evaluation period is extended if I have a recommendation from a friend or colleague. Nevertheless, I make snap judgments on aesthetics, not on the substance of the project.

If I know this about myself, then I need to make a reasonable investment in the initial presentation of this software. Even though our project will be distributed freely, we decided to spend money on the design to make sure our presentation matches the quality of our software.  Unfortunately it costs money to provide a quality open source product.

Conclusions

I have to admit that I have been avoiding this journey for quite a while.  Between the licensing and the project administration I felt a bit overwhelmed.  Nevertheless, I am starting with a small pilot project that has focused and limited functionality.  I’m sure that there will be a lessons learned blog that will emerge out of this experience as time goes on.  Until then have fun sharing your code with the world and check out Source Allies newest open source project at beanoh.org.

Overview

What is Maven?

Maven is a software project management and comprehension tool that includes: build tools, dependency management, project reporting and much more.  I say “much more” because at the core Maven is a plugin execution framework.  There are plugins supported by the Maven project (http://maven.apache.org/plugins/index.html), plugins supported by Mojo Project (http://mojo.codehaus.org/plugins.html), and third party plugins.  If you can find or write a plugin, Maven can run it.

Plugins

Plugins are configured to run during specific phases in the Maven lifecycle.  The high-level phases that make up the build lifecycle include: validation, compile, test, package, integration-test, verify, install, and deploy.  An exhaustive list of build phases can be found at http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference.

Why not Ant and Ivy?

People always gravitate to this question of whether Maven is better than Ant and Ivy.  Unfortunately this is not a fare comparison.  Ant is a build tool and Ivy is a dependency management tool.  Maven is not just a build tool or just a dependency management tool.  On the contrary, Maven is a project management tool that embodies software development best practices.

To illustrate this point I will share a story from my early years in software development.  Our shop used Ant without Ivy.  Ivy didn’t become a full fledged Apache project until October, 2007.  Each team had their own Ant build.  As we began to move from team to team we had to find out which targets needed to be run.  Over time we decided on a set of names that every team needed to implement.  This helped but just because the target was named the same thing it did not mean they worked the same way.

Long story short, we began to meet to create a shared standard.  During this long process we were introduced to Maven.  Ironically, Maven had accepted standards for many of the issues that we were trying address.  Maven was not just a standard for our company it was a standard for all Maven users.  New employees that were familiar with Maven had a good grasp of how we managed our projects.

Maven provided a standard that not only addressed our concerns as software developers.  It provided a standard solution that supported our corporate: audits, disaster recovery, tracability, and the list goes on.  We were trying to reinvent the wheel with Ant when the Maven community had already solved these problems.

Ant and Ivy are powerful ingredients for designing a custom build process.  Maven however is a powerful solution for building and managing software.  In our case we wanted a solution instead of the ingredients and tools to create our own solution.  Maven satisfied our needs and saved us significant time and money.

But It Downloads the Internet

I can’t tell you how many people have told me that they don’t like Maven because it “downloads the internet”. I find it ironic that many of them like Ivy.  I hate to break the news, but Ivy downloads the internet too. I’m not sure why this is a concern.  Is there a fear that Maven will fill up their hard drive?  Disk space is cheap.  The computer I am working on right now has 150GB of hard disk space and my Maven local repository is eating up 300MB of it.  This computer has pleanty of room for more of the internet.

I recall the first time that I tried to setup a new project without a dependency management tool.  I spent over a week trying to download the correct version of each JAR.  I was ready to take a vacation by the time I finished this ugly puzzle.  After using Maven and Ivy for managing my  dependencies I will never go back.  By the time I downloaded all the JARs that we needed, I felt like I had in fact downloaded the entire internet.

I love dependency management tools and they can have as much of my hard drive as they need.

Spring is an essential part of my technology stack. I cann’t image providing quality software that doesn’t leverage an IoC container. However, decoupling components requires some amount of configuration. Whether this is accomplished through annotations or XML, it’s fairly easy to mess up. Fixing these missing or incorrect configurations doesn’t take very long. The real question is how quickly can you identify these errors?

This question of how long, is a feedback loop question. Unfortunately many teams wait until they fire up the application server to see if their Spring context is wired correctly. This is too late.

One of our clients suffered from this very issue. Due to environmental constraints they could not run automated, in-container tests that would have identified misconfigured beans. After repeatedly committing stupid configuration mistakes, I decided that I would write a Spring wiring test. As I began to write this I encountered five problems.

Problem 1: Scope

The first problem that I encountered was that not all of my beans were being created when I loaded my context.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class SpringWiringTest{
 
     @Test
     public void testSomething(){
...

I quickly remembered that only beans with the default ’singleton’ scope will be loaded immediately. The rest of the bean scopes (’prototype’, ‘request’, and ’session’) will not be created until they are requested. In order to solve this I looped through all of the bean names and retrieved each bean from the context.

String[] names = context.getBeanDefinitionNames();
for(String name : names){
     context.getBean(name);
}

However, when I ran this I got the following error

java.lang.IllegalStateException: No Scope registered for scope 'request'

In order to correct this issue I added the following setup method.

@Before
public void testCaseSetUp(){
     context.getBeanFactory().registerScope("session", new SessionScope());
     context.getBeanFactory().registerScope("request", new RequestScope());
     MockHttpServletRequest request = new MockHttpServletRequest();
     ServletRequestAttributes attributes =
          new ServletRequestAttributes(request);
     RequestContextHolder.setRequestAttributes(attributes);
}

I threw in the session scope too just to be safe.

Problem 2: Abstract Bean Definitions

The second problem that I had to solve was requesting abstract beans.

org.springframework.beans.factory.BeanIsAbstractException: Error creating bean
with name 'testBean': Bean definition is abstract

In order to solve this issue I added a check to verify if a bean definition was abstract.

String[] names = context.getBeanDefinitionNames();
for(String name : names){
     BeanDefinition beanDefinition = context.getBeanDefinition(name);
     if(!beanDefinition.isAbstract()){
          context.getBean(name);
     }
}

Problem 3: Mock Beans

The third issue I found was environment specific beans. JNDI references are one type of environment specific bean.

<jee:jndi-lookup id="testBean" jndi-name="jdbc/test"/>

In order to solve this issue, I decided to create a test bootstrap context that imported all of the production contexts. This provided a place for me to override beans that I wanted to create for the test. I used Mockito to create mock beans in most situations.

<bean id="testBean" class="org.mockito.Mockito" factory-method="mock">
<constructor-arg value="com.something.Foo" />
</bean>

While this worked for most beans, I received errors when I wired up mock DataSources. Instead I used embedded databases to replace real DataSources.

<bean id="testDataSource"
class="org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseFactoryBean"
p:databaseType="H2"
abstract="true"/>

Problem 4: Components

This fourth issue was harder to identify but equally problematic. I frequently wired up beans with the @Component annotation and failed to configure an ‘component-scan’ for those packages.

<context:component-scan base-package="com.sourceallies"/>

In other words I needed to reconcile the classes marked with the @Component annotation with the beans that were available in the Spring context.

ClassPathScanningCandidateComponentProvider scanner =
     new ClassPathScanningCandidateComponentProvider(true);
scanner.addIncludeFilter(new AnnotationTypeFilter(Component.class));
for (BeanDefinition bean : scanner.findCandidateComponents("com.something")){
      components.add(bean.getBeanClassName());
}

This will create a list of components found on the classpath under the specified base package. Reconciling this list with the beans loaded in the Spring context will identify any components that are not configured in Spring. This list came in handy for two reasons. First it identified any components that I needed to configure in Spring. Second it listed components that were provided in dependent jars. This list helped us become proactive instead of reactive.

Problem 5: Duplicate Bean Definitions

The fifth issue is duplicate bean definitions. This can occur when more than one bean has the same bean definition name. This can also occur when the same context is loaded multiple times. By default Spring allows the new bean definition to overwrite the previous one. This sounds annoying but harmless. On the contrary, Spring does not guarantee the loading order. Furthermore, each deployment environment’s classloader can load context files in a different order. The bottom line is that duplicate bean definitions can result in subtle and painful bugs.

While this issue was clear to me the solution was a bit more illusive. At first I tried to set the allowBeanDefinitionOverriding flag on org.springframework.beans.factory.support.DefaultListableBeanFactory. This throws an exception if the same bean definition is loaded multiple times. Case closed, right?

Unfortunately the solution was not this simple. Problem 3, Mock Beans, requires the creation of a test bootstrap context that overrides bean definitions. So the allowBeanDefinitionOverriding flag is out. After crying a little, I started exploring Spring. Long story short, I overrode the ‘protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)’ method on org.springframework.context.support.ClassPathXmlApplicationContext and injected a delegating proxy.

@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
		throws BeansException, IOException {
	Enhancer enhancer = new Enhancer();
	enhancer.setSuperclass(DefaultListableBeanFactory.class);
	BeanohBeanFactoryMethodInterceptor callback = new BeanohBeanFactoryMethodInterceptor(
			beanFactory);
	callbacks.add(callback);
	enhancer.setCallback(callback);
	DefaultListableBeanFactory proxy = (DefaultListableBeanFactory) enhancer
			.create();
 
	super.loadBeanDefinitions(proxy);
}

I used ‘net.sf.cglib.proxy.Enhancer’ and ‘net.sf.cglib.proxy.MethodInterceptor’ to create a proxy. The trick was to delegate to the real ‘org.springframework.beans.factory.support.DefaultListableBeanFactory’ instance.

@Override
public Object intercept(Object object, Method method, Object[] args,
		MethodProxy methodProxy) throws Throwable {
	Method delegateMethod = delegateClass.getMethod(method.getName(),
			method.getParameterTypes());
	if ("registerBeanDefinition".equals(method.getName())) {
		if (beanDefinitionMap.containsKey(args[0])) {
			List definitions = beanDefinitionMap
					.get(args[0]);
			definitions.add((BeanDefinition) args[1]);
		} else {
			List beanDefinitions = new ArrayList();
			beanDefinitions.add((BeanDefinition) args[1]);
			beanDefinitionMap.put((String) args[0], beanDefinitions);
		}
	}
	return delegateMethod.invoke(delegate, args);
}

This passively collects bean definitions that are registered with the registerBeanDefinition method. This method takes two arguments: a String bean name (arg[0]) and a ‘org.springframework.beans.factory.config.BeanDefinition’ (arg[1]). This map of bean definitions can be inspected later to determine if beans were loaded multiple times.

Conclusions

This experience has lead our team to develop a complete, open source solution called Beanoh (pronounced \’beanˌō\). Simply download the jar or build the project with maven and start using it.

public class SomeTest extends BeanohTestCase {
 
	@Test
	public void testSomething() {
		assertContextLoading();
	}
}

For more information visit http://beanoh.org/overview.html.

In just a few short weeks this testing approach prevented our team from committing broken Spring configurations. Furthermore, we took time to evaluate the inherited components that we received through our project dependencies. This provided valuable insights into our dependency structure and our packaging strategy.

These wiring tests even gave us feedback as we refactored our spring contexts. We were able to simplify our context files without worrying that we would break something. We also identified unused and duplicate bean definitions. Without the quick feedback of this wiring test we would have committed broken changes that effected the whole team.

Automated tests help you manage code behavior rather than allowing code to drive your behavior. Download Beanoh today and take control of your Spring configuration.

For more information checkout our YouTube video tutorials.

public class MockitoTest {
 
   private EmailFactory emailFactory;
   private Notifier notifier;
   private Emailer emailer;
   private Email email;
 
   @Before
   public void setUp(){
      notifier = new Notifier();
 
      emailFactory = mock(EmailFactory.class);
      emailer = mock(Emailer.class);
      email = mock(Email.class);
 
      notifier.setEmailFactory(emailFactory);
      notifier.setEmailer(emailer);
   }
 
   @Test
   public void testSend(){
      when(emailFactory.create()).thenReturn(email);
 
      notifier.send();
 
      verify(emailFactory).create();
      verify(emailer).send(email);
      verifyNoMoreInteractions(emailFactory);
      verifyNoMoreInteractions(emailer);
   }
}

   public class Notifier{
      private EmailFactory emailFactory;
      private Emailer emailer;
 
      public void send(){
         Email email = emailFactory.create();
         emailer.send(email);
      }
 
      public void setEmailer(Emailer emailer) {
         this.emailer = emailer;
      }
 
      public void setEmailFactory(EmailFactory emailFactory) {
         this.emailFactory = emailFactory;
      }
   }

Here is the code using the new annotations.

@RunWith(MockitoJUnitRunner.class)
public class MockitoAnnotationsTest {
 
   @Mock private EmailFactory emailFactory;
   @Mock private Emailer emailer;
   @Mock private Email email;
   @InjectMocks private Notifier notifier = new Notifier();
 
   @Test
   public void testSend(){
      when(emailFactory.create()).thenReturn(email);
 
      notifier.send();
 
      verify(emailFactory).create();
      verify(emailer).send(email);
      verifyNoMoreInteractions(emailFactory);
      verifyNoMoreInteractions(emailer);
   }
}

   public class Notifier{
      private EmailFactory emailFactory;
      private Emailer emailer;
 
      public void send(){
         Email email = emailFactory.create();
         emailer.send(email);
      }
   }

This new annotation style reduced the number of lines of code by over 40%. The longer a test is the harder it is to understand. Reducing the amount of test code increases its clarity.

So how does it work? ‘@Mock’ is equivalent ‘Mockito.mock(Some.class)’. ‘@InjectMocks’ is equivalent to setting the mocks on the class under test. This annotation uses reflection to set properties so you do not have to add setters just for testing. Lastly, the combination of ‘@RunWith(MockitoJUnitRunner.class)’ and ‘@InjectMocks’ enables you to remove the ‘@Before’ method. This pair of annotations prepares the class under test before each test method.

I have been using mocks in tests for years and this is a great addition to this powerful framework.