Spicy Spring : Different ways of Autowiring

I would like to show different ways of using Spring’s @Autowired annotation: Constructor, Method and Field autowiring.
The examples I show are all a form of byType autowiring mode (constructor autowiring mode is Analogous to byType). Take a look at the Spring Reference guide for more information on the Autowiring modes.

Constructor Autowiring

Create a constructor with a dependent bean as constructor parameter and add the @Autowired annotation to the constructor. A big advantage of autowiring by constructor is that the field can be made final, and therefore may not be changed after construction.

Method Autowiring

Create a setter method for the dependent bean and add the @Autowired annotation to the setter method. A disadvantage of using Method autowiring is that the setter can be called in production code, overriding the bean accidentally.

Field Autowiring

Create a field (member variable) for the dependent bean and add the @Autowired annotation to the field. This way of Autowiring has less code, but takes more effort to test the AutowiredCapabilityBean with an implementation of the InjectableBean, since there is no constructor and no setter for it.

Groovy Goodness: Use Constructor as Method Pointer

In Java 8 we can create a constructor reference. We must use the syntax Class::new and we get a constructor reference. This syntax is not supported in Groovy, but we can use the method pointer or reference syntax .& to turn a method into a closure. We can even turn a constructor into a closure and use it everywhere where closures are allowed.

Continue reading

Compare JAR files content; decompiling class files

When I was recently working on a large restructuring and refactoring where I also replaced Ant by Maven, it was really necessary to compare the complete content of two¬†different JAR files. It was required to know that the result of the restructuring and refactoring hadn’t changed the artifacts, thus the JAR files.
In the JAR files were different Class files present. When I compared the content of the two JAR files (with a binary compare) all the content was radically changed. This was partly because the compiler compiled the Class files at a different timestamp.

Since I wanted the best possible comparison between the two JAR files I needed to compare all Class files in the JAR by decompiling and comparing. This should give me a clearer and more honest picture of the differences. For this action I used Beyond Compare. By using an additional File Format (Java Class to Source) I was able to completely compare the decompiled Class files of the two JARS.

If you ever need to compare JAR, WAR or EAR files and need to compare the Class files inside; don’t try to unpack to a folder, decompile to a different folder and finally folder compare. You should use Beyond Compare and save time on comparing. The Beyond Compare license will pay itself off.

Gradle Goodness: Init Script for Adding Extra Plugins to Existing Projects

Gradle is very flexible. One of the ways to alter the build configuration is with initialization or init scripts. These are like other Gradle scripts but are executed before the build. We can use different ways to add the init script to a build. For example we can use the command-line option -I or --init-script, place the script in the init.d directory of our GRADLE_HOME directory or USER_HOME/.gradle directory or place a file init.gradle in our USER_HOME/.gradle directory.

Continue reading

Gradle Goodness: Running Java Applications from External Dependency

With Gradle we can execute Java applications using the JavaExec task or the javaexec() method. If we want to run Java code from an external dependency we must first pull in the dependency with the Java application code. The best way to do this is to create a new dependency configuration. When we configure a task with type JavaExec we can set the classpath to the external dependency. Notice we cannot use the buildscript{} script block to set the classpath. A JavaExec task will fork a new Java process so any classpath settings via buildscript{} are ignored.

Continue reading

Grassroots Groovy: Parse XML with XmlSlurper from Java

We can introduce Groovy into our Java projects at grassroots level. Even if we aren’t allowed to run the Groovy compiler we can use other ways to run Groovy code. As long as we can include the Groovy libraries as a compile dependency than we can already use Groovy from Java. In this post we see how we can use the power of XmlSlurper to parse XML from our Java code.

Continue reading

Tasty Test Tip: Test final and static methods with PowerMock and Mockito

Two of the most famous mocking frameworks EasyMock and Mockito, don’t offer out of the box support for mocking final and static methods.

It is often said on forums that “you don’t want that” or “your code is badly designed” etc. Well this might be true some of the time, but not all of the time. Continue reading

Tasty Test Tip: Using ArgumentCaptor for generic collections with Mockito

Mockito has a very nice feature that allows you to verify what parameters were used when a method was executed.

For example:

However, when using generic typed objects, some problems rise up.
For example, the following won’t work:

This is obviously not a Mockito problem, but a generics problem.

To solve this, follow these two steps:

1. use the @Captor annotation.

2. initialize the Mockito annotations in your initialization method (add one if you don’t have one).

And presto! You can now capture the parameters that were used when a to be verified method was executed.

Google Guava Goodness: Converting Between ASCII Case Conventions

The Google Guava libraries contains useful utility classes and methods. If we want to convert between ASCII case conventions we can use the CaseFormat class. The class defines constants for upper and lower case CamelCase, upper and lower case hyphenated and upper case underscore. This means we can convert UPPER_VALUE to upper-value with a simple line of code.

(Sample with Google Guava version 13.0.1)

Original article