Have a look at the following to see what happens:


> db.Person.save({"name" : "foo" })
> db.Person.ensureIndex({"name":1})
> db.Person.getIndexes()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"ns" : "test.Person",
"name" : "_id_"
},
{
"v" : 1,
"key" : {
"name" : 1
},
"ns" : "test.Person",
"name" : "name_1"
}
]
> db.Person.save({"name" : "foo" })
> db.Person.find()
{ "_id" : ObjectId("4ee9ab58e57f00e1f3ca95c7"), "name" : "foo" }
{ "_id" : ObjectId("4ee9ab63e57f00e1f3ca95c9"), "name" : "foo" }
> db.Person.ensureIndex({"name":1},{"unique":true, "dropDups":true})
> db.Person.find()
{ "_id" : ObjectId("4ee9ab58e57f00e1f3ca95c7"), "name" : "foo" }
{ "_id" : ObjectId("4ee9ab63e57f00e1f3ca95c9"), "name" : "foo" }
> db.Person.getIndexes()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"ns" : "test.Person",
"name" : "_id_"
},
{
"v" : 1,
"key" : {
"name" : 1
},
"ns" : "test.Person",
"name" : "name_1"
}
]


@Entity
public class MyEntity {
...
    @Autowired @Transient
    private SomeService someService;

}

Notice the @Transient annotation that tells Morphia to avoid persisting this field! I solved this problem by adding an EntityInterceptor that autowires all entities:

public class SpringAutowiringEntityInterceptor extends AbstractEntityInterceptor {
	@Autowired
	private ApplicationContext applicationContext;

    @Autowired
    private Morphia morphia;

	@PostConstruct
	public void postConstruct() {
		morphia.getMapper().addInterceptor(this);
	}

	@Override
	public void preLoad(Object ent, DBObject dbObj, Mapper mapr) {
		applicationContext.getAutowireCapableBeanFactory().autowireBean(ent);
	}
}

Here is the complete source code SpringAutowiringEntityInterceptor.java. Let me know what you think!

Type conversion is done by Camel either when you explicitly tell Camel to perform conversion or in some cases where Camel detects that a type conversion is needed. For example in this case Camel tries to perform type conversion from SourceType to TargetType:

public class SourceType {
    private final int value;

    public SourceType(int value) {
        this.value = value;
    }
}
public class TargetType {
    private final int value;

    public TargetType(int value) {
        this.value = value;
    }
}
public interface Service {
    public void call(TargetType value);
}
...
from("direct:call").bean(service, "call");
...
template.requestBody("direct:call", new SourceType(17));

This will fail since there is no type converter registered to handle conversion to TargetType. What if TargetType has a constructor taking a SourceType:

public TargetType(SourceType source) {
    this.value = source.getValue();
}

But this will also fail! My solution is to add a FallbackConverter that can handle this scenario, that is the target type having a single argument constructor taking the source type. The code looks like this:

package com.jayway.camel.typeconverter;

@Converter
public class UsingConstructor {
    @SuppressWarnings("unchecked")
    @FallbackConverter
    public static <T> T convertTo(Class<T> type, Object value, TypeConverterRegistry registry) throws Throwable {
        for (Constructor<?> c : type.getConstructors()) {
            Class<?>[] types = c.getParameterTypes();
            if (types.length == 1 && types[0].isAssignableFrom(value.getClass())) {
                    return (T) c.newInstance(value);
            }
        }
        return null;
    }
}

A couple of things to notice:

• The class has the @Converter annotation
• The method has the @FallbackConverter
• The signature of the method

You also need to include file META-INF/services/org/apache/camel/TypeConverter in your classpath that contains the package name. This allows Camel to automatically discover the type converter class.

com.jayway.camel.typeconverter

Here is an integration test showing this example. I have also implemented a type converter that checks if the source type has a no argument method returning the target type. The source code for both type converters are available at GitHub.

Notice that this is just a demo of the capabilities of fallback converters. You have to decide if this approach is appropriate in your project. It might not be desirable to have a direct dependency between the TargetType and the SourceType. The overhead of reflection might be too high or it might have unintended consequences. For example the UsingMethod converter has the unintended consequence of finding and using the toString() method when a conversion to String is needed. The UsingConstructor is probably faster and safer since there are usually fewer constructors than public methods.

See the Camel documentation for type converts for more information.

• Maven URL handler that allows deployment directly from a Maven repository
• Features that allow grouping of OSGi bundles

Although these features are not part of the OSGi standard, it at least makes my life easier and I believe that something similar will become part of the standard since Spring DM and Apache Aries also have similar concepts. I'll just show how to create a blank OSGi project and deploy in Karaf:

mvn org.ops4j:maven-pax-plugin:create-bundle -Dpackage=com.jayway.osgi.helloworld
cd com.jayway.osgi.helloworld/
mvn clean install

Now you need to download Karaf, unzip and then:

cd $KARAF_HOME
bin/karaf
osgi:install --start mvn:com.jayway/com.jayway.osgi.helloworld/1.0-SNAPSHOT

The output will be (it is not a completely blank project!):

STARTING com.jayway.osgi.helloworld
REGISTER com.jayway.osgi.helloworld.ExampleService

To generate an Eclipse project:

mvn org.ops4j:maven-pax-plugin:eclipse

Some links:

• Apache Karaf have a good quick start page
• Apache Camel OSGi tutorial

The webservices are:

• The Airport Information Webservice to find the location of an airport
• The National Digital Forecast Database Webservice provided by http://www.weather.gov/ to find the weather at a location

My goals have been:

• Use web services from different providers
• Be able to test the routes
• Include error handling
• Try various methods for transformation

So far I'm quite happy with the results and impressed with the flexibility of Apache Camel. Have a look at the code available at AirportWeather project @ GitHub and let me know what you think.

Routes

The complete route looks like this:

from("direct:getMaximumTemperaturAtAirport")
	.to("direct:getAirportInformationByAirportCode")
	.to("direct:fromAirportInformationToLocation")
	.to("direct:fromLocationToNDFD")
	.to("direct:fromNDFDToTempInCelcius");

The flow is synchronous and each step is implemented in a separate route to be testable, for example I can stub out entire steps of the route.

A step can be further broken down into even smaller routes, for example separating the call to the web service and the error handling:

from("direct:getAirportInformationByAirportCode")
	.to("direct:invokeGetAirportInformationByAirportCode")
	.choice()
		.when().xpath("count(/NewDataSet/Table)=0").rollback("No Airport found")
		.otherwise();

Calling a SOAP web service

To call the web service I use Spring WS. The reason I didn't use CXF is that the NDFD is using RPC encoding which is an old web standard not supported by the current version of CXF. The XML payload is generated using a Velocity template. This works well in this case, but later I want to compare this to JAXB generated objects from an XML schema.

from("direct:invokeGetAirportInformationByAirportCode")
    .to("velocity:getAirportInformationByAirportCode.vm")
    .to("spring-ws:http://www.webservicex.net/airport.asmx?soapAction=http://www.webserviceX.NET/

Transformation

Camel has very flexible support for transformation and un/marshalling. I have tried a couple of different variations. Registering a object and simply calling a method:

SimpleRegistry registry = new SimpleRegistry();
registry.put("temperatureTransformer", new TemperatureTransformer());
...
.transform().method("temperatureTransformer", "fromFahrenheitToCelsius");

Let Camel figure out which method to call:

registry.put("cdataTransformer", new CDataTransformer());
...
.transform().method("cdataTransformer");

XML unmarshalling using XStream:

XStreamDataFormat xmlToAirPortLocation() {
    XStream xstream = new MissingFieldIgnoringXStream();
    xstream.alias("Table", AirportLocation.class);
    XStreamDataFormat dataFormat = new XStreamDataFormat(xstream);
    return dataFormat;
}
...
.unmarshal(xmlToAirPortLocation())

XPath transformation:

.transform().xpath("/NewDataSet/Table[1]")

Let Camel figure out how to perform the conversion:

.convertBodyTo(Integer.class)

Stubbing routes

When testing I used AdviceWith to stub out a route in the test case. I'm not really sure if this is the best way, but it works.

context.getRouteDefinitions().get(0).adviceWith(context, new AdviceWithRouteBuilder() {
    @Override
    public void configure() throws Exception {
        interceptSendToEndpoint(someEndpoint)
            .skipSendToOriginalEndpoint().to("velocity:AirportResult-empty.xml");
    }
});

To make the stub actually override the endpoint it is important to call skipSendToOriginalEndpoint. I use Velocity to generate a static reply. See the AirportWeatherTest for more details.

Handling bad results

To verify the result of the invoked web service I have used a choice and rollback to signal the error, for example when the airport does not exist:

.choice()
    .when().xpath("count(/NewDataSet/Table)=0").rollback("No Airport found")
    .otherwise();

Future Camel rides

Things I will investigate further:

• Other ways to stub out routes
• Making use of camel-test
• Use CXF and JAXB to avoid creating XML payloads using Velocity (perhaps for some other web service)

What is my interest in all this except that I'm really into cool gaming ideas? Well, Minecraft is written in Java and it is easy to write plugins. Currently there is no official support for mods or plugins, although there probably will be in the future. However, there is lots of unofficial mods and the most promising server side mod seems to be Bukkit which supports plugins. Their wiki includes descriptions how to setup your workspace and how to write a plugin. The best way to learn is probably to take a look at the source of one of the many existing plugins.

There is a sample project available called SamplePlugin which you can use to get started quickly. I have added a simple maven profile that makes it even easier to get started:

git clone https://github.com/jankronquist/SamplePlugin.git
cd SamplePlugin
mvn package -Pstart-server


Happy hacking!

Building the plugin

Building a plugin using maven is easy, simply add the following to your pom:

 
<properties>
	<jmeter.home>installation directory of jmeter</jmeter.home>
</properties>
 
<dependencies>
	<dependency>
		<groupId>org.apache.jmeter</groupId>
		<artifactId>jmeter-core</artifactId>
		<version>2.3.4</version>
		<scope>system</scope>
		<systemPath>${jmeter.home}/lib/ext/ApacheJMeter_core.jar</systemPath>
	</dependency>
	<dependency>
		<groupId>org.apache.jmeter</groupId>
		<artifactId>jmeter-jorphan</artifactId>
		<version>2.3.4</version>
		<scope>system</scope>
		<systemPath>${jmeter.home}/lib/jorphan.jar</systemPath>
	</dependency>
</dependencies>

You probably want to put jmeter.home in your settings.xml instead.

Testing the plugin

Whenever I develop something I want to have a quick build/test cycle. In this case I want to to start the JMeter UI without having to update the JMeter installation or any other manual work. I didn't get chronos to add my plugin to the UI. It seems chronos copied the jar files to JMETER_HOME/lib/junit and this probably works for running an already created test, but not for creating the test. I also failed to the the maven exec plugin to create the command line arguments I needed. Instead I added a small ant script to start JMeter:

<build>
<plugins>
<plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-antrun-plugin</artifactId>
      <configuration>
        <tasks>
<property name="runtime_classpath"
           refid="maven.runtime.classpath" />
          <exec executable="${jmeter.home}/bin/jmeter.bat">
            <arg value="-Jsearch_paths=${runtime_classpath}" />
          </exec>
        </tasks>
      </configuration>
    </plugin>
  </plugins>
</build>

To run the jmeter gui simply run mvn antrun:run. This only works for Windows, I leave other platforms as an exercise to the reader .

Using the plugin

I ended up copying the plugin jar and dependencies to the JMeter installation and used then this modified JMeter distribution when performing the tests. The reason was that I didn't have maven installed on some of the test clients. To copy dependencies you can use mvn dependency:copy-dependencies.
If you want to run JMeter using maven you probably want to look at chronos (although it is not released it seems to work fine):

Using Maven Chronos Without an External JMeter Install

Automated performance testing using JMeter and Maven

public class Sneak {
    public static RuntimeException sneakyThrow(Throwable t) {
        if ( t == null ) throw new NullPointerException("t");
        Sneak.<RuntimeException>sneakyThrow0(t);
        return null;
    }

    @SuppressWarnings("unchecked")
    private static <T extends Throwable> void sneakyThrow0(Throwable t) throws T {
        throw (T)t;
    }
}

// this is easy since everything are Strings
scala> List("one", "two", "three")
res0: List[java.lang.String] = List(one, two, three)

scala> res0.foreach(x => println(x.length()))
3
3
5

// with a mixed collection it gets harder
scala> List("one", 2, "three", 4.0)
res2: List[Any] = List(one, 2, three, 4.0)

scala> res2.foreach(x => println(x.length()))
<console>:6: error: value length is not a member of Any

// it is not enough to just filter out the objects that are Strings
scala> res2.filter(_.isInstanceOf[String])
res4: List[Any] = List(one, three)

// as we still have a List of Any
scala> res4.foreach(x => println(x.length()))
<console>:7: error: value length is not a member of Any

// both filtering and mapping is needed
scala> res2.filter(_.isInstanceOf[String]).map(_.asInstanceOf[String])
res6: List[String] = List(one, three)

// finally it works
scala> res6.foreach(x => println(x.length()))
3
5

// another option is to use pattern matching
scala> res2.foreach(_ match { case x:String => println(x.length); case _ => })
3
5

I wanted a more elegant solution with less boiler plate so after playing around with implicit conversions and reified types I managed to come up with rather nice solution:

// define a class that implements a restrictTo method
scala> class IterableWithRestrictTo[A](from:Iterable[A]) {
     | def restrictTo[B](implicit m: scala.reflect.Manifest[B]) = {
     | from.filter(m.erasure.isInstance(_)).map(_.asInstanceOf[B])
     | }
     | }
defined class IterableWithRestrictTo

// define implicit conversion
scala> implicit def makeIterableWithRestrictTo[A](from : Iterable[A]) = {
     | new IterableWithRestrictTo(from)
     | }
makeIterableWithRestrictTo: [A](from: Iterable[A])IterableWithRestrictTo[A]

scala> List("one", 2, "three", 4.0)
res0: List[Any] = List(one, 2, three, 4.0)

// restrict to objects of type String
scala> res0.restrictTo[String]
res1: Iterable[String] = List(one, three)

// works since the collection have correct type
scala> res1.foreach(x => println(x.length()))
3
5

Using the name restrictTo clearly shows that not only is there a type conversion, but also a restriction to a subset of the elements. Notice that the manifest is needed to get the reified type, since the type B is actually erased at compile time. Read more about reified types in Scala.

Let me know you have another solution!

The problem was that JManage 2.0-RC1 does not support WebLogic 10.3 and their last release was made two years ago. However, since they support version 9 I figured it might be possible to upgrade the jar files to make it work with 10.3. This is how you do it:

In the folder $JMANAGE_HOME/modules/weblogic9 remove wljmxclient.jar and add wlfullclient.jar and com.bea.core.descriptor.wl_1.1.0.0.jar instead. Here are the instructions how to create the wlfullclient.jar. The other jar is included in $BEA_HOME/modules.

I have also tried jconsole, the built-in WLDF console extension and wlnav but all of them had problems:

Although JManage is good enough for my current purposes I am interested in other alternatives for remote JMX management of WebLogic!

We now think that the API is stable enough and we have also tested PowerMock in a couple of projects, but of course since we were presenting at the conference it is no coincidence that we released PowerMock 1.0 just days before.

The details of the changes can be found in the changelog but here are some of the highlights since PowerMock 0.8:

• The ability to set and get internal state based on an object type. This means that you get more refactor friendly code while still being able to set internal state.
• Implemented replayAll and verifyAll. These can be used to replay and verify all mocks created by PowerMock without having to explicitly specify each and everyone. Thanks to Ivar Grimstad for suggesting this!
• Added support for specifying parameter types for expectNew. Mocking constructor calls is a unique feature of PowerMock that people typically find very cool!

During the conference I talked to several people and got really good feedback. Everybody seemed to like the idea of being able to unit test legacy code and code that haven't been designed for testing. Kevlin Henney made a good job of defining and describing various types of unit testing during his talk at Øredev and we talked about the difference between essentially untestable code and accidentally untestable code. PowerMock solves the problem with code being untestable for technical reasons (part of the accidentally untestable). With all the great sessions and good discussions Øredev was yet again a great experience!

I have made the slides from the presentation available at powermock.org. Note that the demo we showed was actually from the trunk and not from the 1.0 release!

Here is screenshot from the management console showing 81 active CPUs and 23 GB free memory:

I tried some Scala actors which worked very well. By running some CPU intensive calculations I concluded that it scaled linearly up to the number of CPUs. No surprise, but very cool when you are running 80 threads at full speed! Also cool to see that Scala runs smoothly which means that neither Scala nor Azul does anything strange. Just pure bytecode.

Somebody tried to configure the Azul JVM in Eclipse and was able to run JUnit tests on Azul. We were also able to run maven without any problems.

We tried to allocate lots of memory. No problem there either, although we had to specify -Xmx10G or something. By default you only get 1.6 GB....

A colleague started tomcat, produced lots of garbage and tried garbage collection at 8 GB of heap. No pause! However, there was some synchronization problem with Log4j since all 16 CPUs had to coordinate their work.

We encountered two problems:

• xstream apparently had a dependency to Unsafe which is not supported on Azul
• the program must be headless, so no Swing

A quick rewrite later and we had generated a 64 megapixel mandelbrot calculated in parallel on 40 CPUs. The only problem was saving the PNG file which was a single threaded operation...

Guy Steele pointed out that what is good practice for sequential programming might be very bad practice for parallel programming. For example in parallel algorithms you want to limit synchronization and avoid communication between parallel computations and therefore it is ok to use more memory and more CPU cycles to avoid this. Erik Meijer tried to brainwash us all to use Haskell, and succeeded in some ways as people started talking about monads and IO all evening.

Gregor Hohpe talked about what Google is doing to create extremely scalable systems. He talked about a new definition of ACID in cloud computing. Associative (the order the operations are combined is not important), Commutative (order of execution is not important), Idempotent (when an operation is executed multiple is has the same result every time) and Distributed. He also recommended Pat Helland's excellent paper on near infinity scalability.

Another cool presentation was Michele Lanza's code visualization tools based on ideas around iconic memory, ie that you should be able to immediately understand and see what is going on. Check out CodeCity and X-Ray.

This weekend I was unpacking two of the last boxes in my new apartment and I finally found my old Amiga 1200. Since it have been stored in the attic for a couple of years and in before that it was stored in the cellar, I decided that it was time to check if it was still working. It took me a quite some time to configure the TV(!) to correctly show the display, but everything else worked like a charm. It had not been booted for over 10 years!

Anyway I found the source code in some random folder, created an LHA archive, found an old floppy disk and using an USB floppy drive I managed to transfer the archive to my PC. Some facts:

• The code had not been touched since march 1995
• It is more than 12 000 lines of (more or less) undocumented assembly code mostly in a single file
• The labels are things like s, s2, fl, bid, cnl2 and so on
• We didn't use a version control system. Instead all files were transfered on floppy disk between our computers

Yet we were still able to create a fun computer game that worked on all the different versions of the Amiga hardware. With todays powerful hardware, different programming languages, good IDEs and the large number of frameworks I simply don't know where to start. Why is that?

Perhaps the fact that we were very focused on what we wanted to do and not interested in how, we were able to overcome the complexity and simply get it done.

Motivation

When unit testing we would like to test only a single unit of code without any exter-
nal dependencies. However, an object seldom lives in isolation and often has one or
more collaborators, which it communicates with using method calls. Mock objects
is a well known technique (1) that that can be used to simulate the collaborators
and thereby create a totally controlled environment. Mock objects together with
test driven development is also very useful for improving the design as you discover
how your class should be used.
So everything is fine? Well, not everything is an object, even in Java. Sometimes
static methods are used and it is no longer possible to use the mock object technique
as there no longer is an object. But that has a simple solution: “Don’t use static
methods” - right? Sure, if you write all code yourself that is possible, but almost all
projects have external dependencies outside of the project’s control. It is even worse
than you might initially think as Java standard APIs often have lots of static methods.
Some examples:

•Java	SE:	System.getProperty(String name)
•Java	ME:	RecordStore.openRecordStore(String recordStoreName,
                boolean	createIfNecessary) 

Example

In the last issue of JayView there was an article about a tool called MockME that
makes it possible to mock the static methods that are abundant in the Java ME
APIs (2). This article tries to solve this problem in a more general way.
Let us use the same code example which uses the RecordStore from Java ME and
examine the problem again. For those of you unfamiliar with Java ME, RecordStore
is an API for storing byte array records persistently on the phone.

public class RecordStore {
  public static RecordStore openRecordStore(String recordStoreName,
                                            boolean createIfNecessary)
      throws RecordStoreException,
             RecordStoreFullException,
             RecordStoreNotFoundException {
    // implementation goes here
  }
    // ...
}

We now implement a data access object (DAO) that we use to store messages.
It will allow us to store and access messages from a RecordStore without bothering
with the details how the message is stored.

public class MessageDao {
  private static final String RECORD_STORE_NAME = “MessageDao”; 

  public void addMessage(Message message) throws RecordStoreException {
    RecordStore recordStore = null;
    try {
      // This static method invocation is normally hard to mock
      recordStore = RecordStore.openRecordStore(RECORD_STORE_NAME, true);
      byte[] bytes = encodeMessage(message);
      if (message.getId() == -1) {
        message.getId() = recordStore.addRecord(bytes, 0, bytes.length);
      } else {
        recordStore.setRecord(message.getId(), bytes, 0, bytes.length);
      }
    } finally {
      if (recordStore != null) {
        recordStore.closeRecordStore();
      }
    }
  }
}

Desired Solution

In this unit test of MessageDao we only test the happy-flow (when everything goes
fine) to show the principle of static mocking. Please compare this to the MockME
solution.

public class MessageDaoTest extends TestCase {
  private MessageDao messageDao;        // Object under test
  private RecordStore recordStoreMock;  // Mock object 

  // Called by JUnit to initialize the test
  public void setUp() {
    // Create mock object for RecordStore as usual
    recordStoreMock = createMock(RecordStore.class);
    // tell mocking framework that static methods of class RecordStore
    // should be mocked
    staticMock(RecordStore.class); 

    // Create object under test
    messageDao = new MessageDao();
  } 

  // Called by JUnit to clean up after each test run
  public void tearDown() {
    messageDao = null;
  } 

  public void testAddMessage() throws Exception {
    // Set up expected behaviour
    // (This usually doesn’t work)
    expectStatic(RecordStore.openRecordStore(“MessageDao”, true))
      .andReturn(recordStoreMock);
    byte[] expectEncMess = “\u0004from\u0004text”.getBytes();
    expect(recordStoreMock.addRecord(aryEq(expectEncMess), eq(0), eq(10)))
      .andReturn(42);
    recordStoreMock.closeRecordStore(); 

    // Put the mocks in test state
    replayStatic(RecordStore.class);
    replay(recordStoreMock); 

    // Executing the code we want to test
    Message message = new Message(“from”, “text”);
    messageDao.addMessage(message);
    assertEquals(“Wrong message ID”, 42, message.getId()); 

    // Verify the behaviour
    verifyStatic(RecordStore.class);
    verify(recordStoreMock);
  }
}

This test sets up the expected method calls on RecordStore, then invokes the
DAO and finally verifies its behavior. But unfortunately it is not possible to mock
static methods as the binding is done at compile time. Or is it?

Aspects to the rescue

It turns out that this is possible. Using Aspect Oriented Programming (AOP) we
can change the static methods to become mockable. Without going too much into
details, AOP allows us to change the behavior of classes and methods after they have
been compiled. Three things are needed:

• A pointcut that specifies which methods the aspect should change (that is all
  static methods)
• An advice that that allows mocking to replace the original behavior
• An implementation of the mock, replay, verify methods that allows mocking
  classes

Let us start with the setup methods. To keep track of which classes we have
mocked we create a Map that contains an EasyMock MockInvocationHandler for
each class that we mock. MockInvocationHandler is a proxy object that performs
the actual mocking and will receive method invocations instead of the real object.
Notice the use of a Hashtable to make the map accesses thread safe.

public class StaticMock {
    static Map mocks =
        new HashTable(); 

    public static void mock(Class type) {
        MockInvocationHandler h
        = new MockInvocationHandler((MocksControl) EasyMock.createControl());
        mocks.put(type, h);
    } 

    public static void replay(Class type) {
        mocks.get(type).getControl().replay();
    } 

    public static void verify(Class type) {
        mocks.remove(type).getControl().verify();
    } 

}

Then once we intercept a method call to a static method, find out if there is a
MockInvocationHandler associated with that class and if so redirect the call to it.
This method should not be static to avoid infinite recursion. The following advice
does the trick:

public	Object	mockMethodAdvice(ProceedingJoinPoint	jp) throws Throwable {
        // find the InvocationHandler associated with the class
        Class type = jp.getSignature().getDeclaringType();
        InvocationHandler h = mocks.get(type); 

        // if there is no InvocationHandler let the method call proceed
        // as normal
        if (h == null) {
            return jp.proceed();
        } 

        // otherwise redirect the method call to the proxy
        MethodSignature methodSignature
            = ((MethodSignature)jp.getSignature());
        return h.invoke(type, methodSignature.getMethod(), jp.getArgs());
    } 

Finally we need to tell AspectJ which methods it should apply the above advice
to. The following aspect uses a pointcut that catches ALL calls to ALL static meth-
ods (call(static * *(..))). It might be a bit aggressive, but it works! If you want you can
implement your own aspect with a more specialized pointcut, for example specific
to your own application.

@Aspect
public class StaticMockAll extends StaticMock {
    @Pointcut(“call(static * *(..))”)
    public void anyStaticOperation() {}
    @Around(“anyStaticOperation()”)
    public Object aroundStaticMethods(ProceedingJoinPoint jp)
        throws Throwable
    {
        return mockMethodAdvice(jp);
    } 

}

Things to note:

• Static methods can be mocked!
• Native methods can also be mocked this way! By using the “call” pointcut we
  change all code that tries to call the native methods and not the native method
  itself. However, note that class loading issues are not avoided. For example, Java
  ME implementations typically require that native libraries are loaded which
  can cause problems when unit testing.
• AspectJ is required to make this work. I have been using Eclipse AJDT plugin
  when writing and testing this code.

Please download and view the sample code for a simple working example of
using this technique. Go to www.jayway.se/jayview and download the zip file as-
sociated with this issue.

Discussion

There are other are ways to get around this problem. For example you could write
small wrappers around these static methods and then consistently use the wrappers
instead of the underlying implementation. This works, but each project will have
its own wrappers which will probably make it harder to understand than using
standard APIs.
The approach taken by MockME is also an option, especially for handling stand-
ard APIs such as the APIs for Java ME. However, this adds slightly more complexity
to writing the tests, as you need to use the MockME specific methods.
This new solution proposal is still very experimental, but using AOP or some
other technique for bytecode manipulation seems to be a very promising solution
to the problem of mocking static methods. However, to be successful a packaged
solutions needs to:

• be a drop in jar file
• work well with any IDE
• work with build systems such as ant or maven

Conclusion

So now static method are no longer bad design since we can mock them? No, not
really. Static methods are still bad, but we no longer have to sacrifice or complicate
testability when we are forced to use static methods. When writing new code you
should use an object oriented design and use mock objects for your unit tests. The
mocking techniques presented in this article are only a tool for testing things that
weren’t testable before. This allows us to further increase the possible code coverage
of our tests, but our design rules should not change.

References

Sample code available here

1. Endo-Testing: Unit Testing with Mock Objects
2. JayView 13 - Java ME Testing Done Right
3. EasyMock
4. JUnit
5. AspectJ
6. Eclipse AJDT
7. AOP

Originally published in JayView.

 
public class StupidSingleton {
	public static String doStatic(int i) {
		throw new UnsupportedOperationException("method not implemented yet...");
	}
 
	public static void sayHello() {
		System.out.println("Hello");
	}
 
	public static native void nativeMethod();
}
 

We would like to write something like this:

 
	public void testMocking() {
		mock(StupidSingleton.class);
		expect(StupidSingleton.doStatic(17)).andReturn("17");
		StupidSingleton.sayHello();
		StupidSingleton.nativeMethod();
		replay(StupidSingleton.class);
 
		assertEquals("17", StupidSingleton.doStatic(17));
		StupidSingleton.sayHello();
		StupidSingleton.nativeMethod();
 
		verify(StupidSingleton.class);
	}
 

After playing around with AspectJ I discovered that this is actually possible! Two things are needed:
* An aspect that allows us to catch calls to static methods!
* An implementation of the mock, replay, verify for classes

This turns out to be really easy! The following aspect catches ALL calls to ALL static methods. Might be a bit aggressive, but it works! If you want you can implement your own aspect with a more specialized pointcut.

 
@Aspect
public class StaticMockAll extends StaticMockAspect {
	@Pointcut("call(static * *(..))")
	public void anyStaticOperation() {}
 
	@Around("anyStaticOperation()")
	public Object aroundStaticMethods(ProceedingJoinPoint jp) throws Throwable {
		return super.aroundStaticMethods(jp);
	}
 
}
 

The mock, replay, verify methods turns out to be trivial:

 
public class StaticMock {
	static Map<Class, MockInvocationHandler> mocks = new HashMap<Class, MockInvocationHandler>();
 
	public static synchronized void mock(Class type) {
		MockInvocationHandler h = new MockInvocationHandler((MocksControl) EasyMock.createControl());
		mocks.put(type, h);
	}
 
	public static synchronized void replay(Class type) {
		mocks.get(type).getControl().replay();
	}
 
	public static synchronized void verify(Class type) {
		mocks.remove(type).getControl().verify();
	}
}
 

Finally, the base class for the aspect that does the actual work is also quite simple:

 
public class StaticMockAspect {
	public Object aroundStaticMethods(ProceedingJoinPoint jp) throws Throwable {
		Class type = jp.getSignature().getDeclaringType();
		InvocationHandler h = getInvocationHandler(type);
		if (h == null) {
			return jp.proceed();
		}
		MethodSignature methodSignature = ((MethodSignature)jp.getSignature());
		return h.invoke(type, methodSignature.getMethod(), jp.getArgs());
	}
 
	private MockInvocationHandler getInvocationHandler(Class type) {
		synchronized (StaticMock.class) {
			return StaticMock.mocks.get(type);
		}
	}
 
}
 

h3. Notes

Things to note and think about:
* Static methods and native methods can be mocked! By using the "call" pointcut we change all code that tries to call the native methods and not the native method itself.
* AspectJ is required to make this work. I have been using Eclipse AJDT
* It should be possible to replace the Aspect with "plain" byte code manipulation and "just" reload the class.

The problem

A while ago a colleague of mine discovered a weird behavior when writing some integration tests. He fi rst noticed that the test worked in JDeveloper, but not in Eclipse. Then he noticed that he could make a small change to the test setup and the test would pass. Another small change and it would fail again. He got some help and managed to reduce the problem to the following:

Original code

import junit.framework.TestCase;
public class ObjectCreationTest extends TestCase {
        class MyObject {
                Object temp;
                public MyObject() {
                        set();
                }
                void set() {
                }
                Object get() {
                        return temp;
                }
        }
        public void testWithNewString() throws Throwable {
                fi nal String value = new String(”Value”);
                assertEquals(”Value”, value); 

                MyObject tested = new MyObject() {
                        void set() {
                                temp = value;
                        }
                };
                String result = (String) tested.get();
                assertEquals(”Value”, result);
        }
}

This test fails in some environments and works in others. When the test fails it is
because result is null. How can this be? But it gets even stranger: By changing how
the value is initialized the test always pass:

Using a String constant

public void testWithConstant() throws Throwable {
        fi nal String value = ”Value”;
        assertEquals(”Value”, value); 

        MyObject tested = new MyObject() {
                void set() {
                        temp = value;
                }
        };
        String result = (String) tested.get();
        assertEquals(”Value”, result);
}

This test works for all environments. Why does the initialization of value affect
result? Very strange indeed!
Finally, by changing the type of the value we are back to the situation where the test
case fails in some environments, but not all.

Using Object instead of String

public void testWithObject() throws Throwable {
        fi nal Object value = ”Value”;
        assertEquals(”Value”, value); 

        MyObject tested = new MyObject() {
                void set() {
                        temp = value;
                }
        };
        String result = (String) tested.get();
        assertEquals(”Value”, result);
}

Challenge

Here are some challenges for you! Try to solve them before reading the solution!

• Explain the difference between the middle test case and the other two (easy).
• Explain why the initial test case fails in some environments and works in others (hard).
• Find the bad design that might cause problems (and indeed does in this case!).

I can give you a hint. The differences are both related to the Java compiler. Don’t
cheat! You should at least be able to answer the irst question before reading on.

Solution

There are several things going on here. I’ll start by explaining what is going on when
we change the variable named ”value” and then I’ll look more closely at anonymous
inner classes. Finally I will describe the problem with the design.

Constant variablConstant variables

Here are the three cases again:

final String value1 = new String(”Value”);
final String value2 = ”Value”;
final Object value3 = ”Value”;

According to the Java Language Specifi cation (JLS) ”We call a variable, of primitive
type or type String, that is fi nal and initialized with a compile-time constant expres-
sion (§15.28) a constant variable”. Lets go through each variable:

• ”value1” is not a constant since it does not have a compile-time constant expres-
  sion! That is, the compiler does not know what the String constructor is doing and
  therefore assumes that this needs to be evaluated at runtime.
• ”value2” is a constant variable since it is clearly of type String and also initialized with a compile-time constant value.
• ”value3” is not a constant since it is not a primitive type or a String. Yes, the object it refers to is a String, but the variable itself is an Object.

This means that only the middle case is a constant. When the compiler spots a
constant it automatically replaces all references with the constant value, ie in the
compiled class a constant variable is never referenced! The result is that the next
problem I will describe does not occur and the test case works.

Anonymous inner classes

As you know an inner class is able to access not only fi elds in the creating instance
but also fi nal variables in the method that creates the class. Did you ever wonder
how this magic is done? Maybe you have also noticed that it is not possible for an
anonymous class to have a constructor. When you create an anonymous inner class
the compiler actually creates the constructor for you. Let’s decompile the original
version and see what is going on.

Decompiled the original version (using JAD and javap)

final class ObjectCreationTest$1 extends MyObject {
        fi nal ObjectCreationTest this$0;
        private fi nal Object val$value;
        ObjectCreationTest$1(ObjectCreationTest that, Object obj)
                this$0 = that;
                val$value = obj;
                super();
        }
        void set() {
                temp = val$value;
        }
}
public void testWithNewString() throws Throwable{
        fi nal Object value = new String(”value”);
        MyObject tested = new ObjectCreationTest$1(this, value);
        Object result = tested.get();
        assertEquals(value, result);
}

Now it is easy to see that there is no magic going on! The compiler has simply added
a constructor and two instance variables. The set method is not using the fi nal vari-
able from the method, instead it is simply using its own reference to the value.
Well, this is all very nice, but why did the test case fail in some environments?
Notice how the generated constructor fi rst initializes the members and then calls super. This is normally not allowed in Java, but consider what would happen if the
compiler didn’t work this way. MyObject constructor would be called, which then
calls set and tries to use val$value which has not been initialized yet. Because of a
bug in the compiler this is exactly what happened in Java compilers before release
1.4.
OK, so if this problem is fi xed in 1.4 and later, why should you care? Take a look
at the next problem!

Bad design

The problem with the design is that the base class MyObject is calling methods in the
anonymous subclass before the subclass instance variables have been created. Unfor-
tunately this is not only a problem with anonymous classes, but a problem in general.
Take a look at the following test case and see if you know what will happen.

public class BaseCallingSubTest extends TestCase {
        class Base {
                Base() {
                        doStuff();
                }
                void doStuff() {
                }
        }
        class Sub extends Base {
                private fi nal int fi nalField = 5;
                private int normalField = 5;
                void doStuff() {
                        assertEquals(5, fi nalField);
                        assertEquals(5, normalField);
                }
        } 

        public void testSub() {
                Sub s = new Sub();
        }
}

The test case will fail at the second assertEquals. Why? Two things are happening.
First of all ”fi nalField” is a constant variable and the compiler automatically uses 5
instead of referencing the variable, see above. Secondly, the constructor for Base is
called before the fi elds of Sub are initialized! Things are actually happening in this
order:

1. The fields in Base are initialized
2. Base constructor is run
3. The fi elds in Sub are initialized
4. Sub constructor is run

This is not a bug! This is exactly according to JLS Ӥ12.5 Creation of New Class
Instances”. The following is perhaps even more surprising:

public class BaseCallingSub2Test extends TestCase {
        class Base {
                Base() {
                        doStuff();
                }
                void doStuff() {
                }
        }
        class Sub extends Base {
                private int normalField = 5;
                void doStuff() {
                        normalField = 7;
                }
        } 

        public void testBase() {
                Sub s = new Sub();
                assertEquals(7, s.normalField);
        }
}

This test case also fails because after Base and doStuff have been called, Sub is ini-
tialized and the normalField is assigned to 5. This is possible to solve by not initial-
izing normalField.

class Sub extends Base {
        private int normalField;
        void doStuff() {
                normalField = 7;
        }
}

This works as expected. However, try to avoid constructions like this as it is very
easy to forget that the fi elds might not be initialized yet. There are actually more
problems with this construction as it might affect thread safety. For instance if the
subclass starts a thread in the overridden method this thread might be given access
to the uninitialized object. Brian Goetz (author of ”Java Concurrency in Practice”)
goes as far as calling this ”not properly constructed”.

Lessons learned

• Make sure you understand constant variables and how they are used by the compiler
• Use a recent version of Java compiler. Sun is constantly adding improvements and
  fixing bugs.
• Avoid calling non fi nal methods from the constructor. If you have to, be aware
  that the object might not be initialized yet.
• Do not perform unnecessary initialization of fields.

Originally published in JayView.