After searching on Google I found that there are two solutions for the problem which both includes an adapter class:

• Polling - The adapter class polls for changes in the POJO. While this solution is transparent to our POJOs it does not keep the state synchronised and is not very resource efficient.
• Observer-pattern - The adapter class listens for changes in the POJO. This implies that we add listener mechanism to our POJOs and thus not very transparent.

Michael Heinrichs at Sun have a great post about it. The problem is that none of these solutions are really adequate.

The best of both worlds

Since I didn't want to change my POJOs or coding adapters I had to come up with a new strategy. We've seen how listener mechanisms can be added using AOP. Great! By adding an aspect we can mixin the functionality we need for JavaFX to be able to bind to my POJOs. Furthermore we can generate the adapters. We only need to decide what fields we need to bind to in our POJOs. These will serve as our pointcuts. The default strategy would be to select all JavaBean properties. What a great day for coding a tool coding! The result is an easy to use tool that I hosted on Google Code:

http://code.google.com/p/javafxbinder/

For example if I have a POJO like this:

package se.jayway.javafxbinder.example.domain;
 
public class Person {
	private String name;
	private int age;
 
	public Person() {
	}
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		System.out.println("Name was set: " + name);
		this.name = name;
	}
 
	public int getAge() {
		return age;
	}
 
	public void setAge(int age) {
		this.age = age;
	}
}

Using JavaFX binder I can run the following command to generate some JavaFX code:

javafxbinder.sh -classpath ./target/classes -includes se.jayway.javafxbinder.example.domain.* -out ./output

And here is what gets generated:

package se.jayway.javafxbinder.example.domain;
 
import se.jayway.javafxbinder.example.domain.Person;
import se.jayway.javafxbinder.infrastructure.Bean;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
 
public class JfxPerson extends PropertyChangeListener {
    public-init var pojo : Person on replace oldValue {
        var oldBean : Bean = oldValue as Bean;
        oldBean.removePropertyChangeListener(this);
 
        var newBean : Bean = pojo as Bean;
        newBean.addPropertyChangeListener(this);
    };
 
    public var age : Integer = pojo.getAge() on replace {
        pojo.setAge(age);
    };
    public var name : String = pojo.getName() on replace {
        pojo.setName(name);
    };
 
    override public function propertyChange(event : PropertyChangeEvent) {
    	// Make sure that we're updating in the right thread
        FX.deferAction(function() {
            var bean : Bean = pojo as Bean;
            bean.removePropertyChangeListener(this);
            if (event.getPropertyName().equals("age")) {
                age = event.getNewValue() as Integer;
            }
            if (event.getPropertyName().equals("name")) {
                name = event.getNewValue() as String;
            }
            bean.addPropertyChangeListener(this);
        });
    }
}

To enable the listener functionality in my POJO I need to define an aspect:

package se.jayway.javafxbinder.example.domain;
 
import se.jayway.javafxbinder.infrastructure.Bean;
 
public aspect MyJavaBeans {
    declare parents: (se.jayway.javafxbinder.example.domain.Person) implements Bean;
}

Conclusion

Using AOP and a simple code generator is a good solution to the annoying JavaFX bind to Java problem. We use this tool for one of our clients and it works really good. However, my hope goes to someone at Sun/Oracle to integrate a similar functionality in the JavaFX compiler itself... Transparency looks good both in GUIs and in software design!

Introduction

Aspect Oriented Programming (AOP) is gaining popularity within the Java SE/EE communities. There are many advantages of AOP especially as it provides a clear separation of concerns. The code becomes much more modular than with
traditional object technology. It’s not the intent of the article to explain all AOP
concepts and if you’re new to AOP you can find a couple of introduction sites in the
references section. Instead we will show how AOP can be used in CLDC enabled
devices such as mobile phones.
In Java ME applications there haven’t been much use of AOP. In fact, there
haven’t been any AOP frameworks available at all! Until now that is. AspectME
is a new open source project that delivers an AOP framework mainly targeted at
CLDC devices. Maybe most importantly, AspectME adds a reflection API. Reflec-
tion makes it possible to invoke methods and access fields dynamically. Advanced
frameworks use reflection to enable non-intrusive and modular mechanisms. Reflec-
tion is needed in AOP frameworks since we need information about where in the
code the aspect is executing.

What’s in the box?

AspectME consists of a runtime jar file that needs to be packaged together with
your Java ME application. Then we have an aspect weaver that is used to weave the
aspects into the compiled classfiles. During the weaving process necessary reflection
information is also added. What aspects to apply and extra reflection information is
controlled by a configuration file. And that’s all. To conclude, to use AspectME you’ll
need the following:

1. Add aspectmeruntime.jar to your Java ME project.
2. Write a configuration file that defines your aspects.
3. Run the aspect weaver after you’ve compiled your source code.

The assembly and deployment of your application is the same as before. AspectME
doesn’t change or remove debugging information so you can debug your application
as usual. Now, lets look at a small example.

Logging example

The first example is the classic logging example where we want to write enter/exit
outputs to the console around certain methods. Consider the following code:

public class Foo {
  public int bar(String s) {
    return Integer.intValue(s);
  }
}

It would be easy to add System.out statements when we enter and exit the method.
However, it would clutter the code, especially if we want to print out if we exit from
an exception:

public class Foo {
  public int bar(String s) {
    System.out.println(”Enter bar()”);
    try {
      int rv = Integer.intValue(s);
      System.out.println(”Exit bar()”);
      return rv;
    } catch (Exception e) {
      System.out.println(”Exit bar() from exception ” + e);
      throw new RuntimeException(e.getMessage());
    }
  }
}

Instead we can use AspectME and write an advice that can be used to weave logging
functionality into the code:

import org.aspectme.api.MethodInterceptor;
import org.aspectme.api.MethodInvocation;  

public class LoggingAdvice implements MethodInterceptor {
  public Object invoke(MethodInvocation mi) {
    // Create a pretty string
    String methodSignature = mi.getMethod().getName() + ”()”;  

    System.out.println(”Enter ” + methodSignature);  

    // Continue the method invocation
    Object rv = mi.proceed();  

    System.out.println(”Exit ” + methodSignature);
    return rv;
  }
} 

Now we need to define the pointcut where we want to apply the advice. In this case
it’s only one joinpoint, the bar() method, but we could apply the advice to many
joinpoints, e.g. all public methods in a package. AspectME uses the AspectJ pointcut
language because it’s powerful and de-facto standard within the AOP community.
We do this in a XML file:

 <?xml version=”1.0”?>
<aspectme>
  <pointcut id=”barMethod” expression=”execution(* org.aspectme.example.Foo.
bar())” />     

  <advice id=”log” class=”org.aspectme.example.aspects.LoggingAdvice” />  

  <aspect advice-ref=”log” type=”around” pointcut-ref=”barMethod” />
</aspectme>

Note that combining the parameters from the aspect definition actually describes
in “plain english” what the aspect does, “log around barMethod”. Now we’re ready
to weave everything together into the final executable. We do this with the weave
command from a shell:

weave -in classes -f aspectme.xml -out weaved_classes

The weave command will analyze all classes from the classes folder and weave in the
advices according to the definition in the aspectme.xml file. All modified classes will
be written to the weaved_classes folder.
But hey, didn’t we want to write to the console if we leave the method from an
exception? With AOP this becomes a breeze:

public class LoggingAdvice implements MethodInterceptor {
  public Object invoke(MethodInvocation mi) {
    // Create a pretty string
    String methodSignature = mi.getMethod().getName() + ”()”;  

    System.out.println(”Enter ” + methodSignature);  

    // Continue the method invocation
    try {
      Object rv = mi.proceed();  

      System.out.println(”Exit ” + methodSignature);
      return rv;
    } catch (Exception e) {
      System.out.println(”Exit ” + methodSignature + ” with exception ” + e);
      throw e;
    }
  }
} 

Note that we have totally separated the concern of logging in our example. We can
easily change the logging mechanism by editing a single file, even though it’s applied
in hundreds of joinpoints.

Persistence example

The previous example was simple but showed the basics of AspectME. Now lets
concentrate on a more interesting example. Imagine we have an application that will
manage contact information. If designed properly we would have a domain model
consisting of two classes, ContactList and Contact. The ContactList contains zero or
more Contact objects.
The MIDlet would create the ContactList at startup and pass the model to the views.
The views would use the ContactList to add and remove Contact elements. In tradition-
al application design we would add a ContactListDAO that manages the persistence mechanism. The DAO object would be used from the controller whenever a contact is added or removed. Nice design? Not really since the DAO clutters the code and adds unnecessary infrastructure code into our application.
Using the AOP approach we would intercept the execution at certain joinpoints
as shown in the picture. We start by writing a persistence advice:

public class PersistenceAdvice implements MethodInterceptor,
                                          ConstructorInterceptor {  

  /**
   * Stores the target object after invocation.
   * @param invocation The joinpoint of the method invocation.
   * @return The return value from the method invocation.
   */
  public Object invoke(MethodInvocation invocation) throws Throwable {
    // Run the target method
    Object result = invocation.proceed();  

    // Store the object
    store(invocation.getThis());  

    // Return the result
    return result;
  }  

  /**
   * Loads an object from the record store instead of creating it.
   * @param invocation The joinpoint of the constructor call.
   * @return The created object.
   */
  public Object construct(ConstructorInvocation invocation) throws Throwable
{
    Object obj = load();
    // If this is the first time we load the object we’ll get a null object.
    // In that case we need to create the object, i.e. proceed with the
    // normal execution.
    if (obj == null) {
      obj = invocation.proceed();
    }
    return obj;
  }  

  private void store(Object obj) throws IOException {
    // Store the passed object into the record store by serializing it
    // to the record store
  }  

  private Object load() throws IOException {
    Object obj = null;
    // Load the specified object from the record store
    return obj;
  }
}

The advice implements both the MethodInterceptor and ConstructorInterceptor.
The MethodInterceptor is used to intercept methods that changes the object and
store them in the record store. In our case the ContactList. The ConstructorIn-
terceptor is used to intercept the creation of ContactList objects, so rather than
creating them it will load them from the record store. This means that anywhere in
the code we execute “new ContactList()” we would load the object and return the
loaded object instead of creating it.
The serialization of objects can be made using the reflection API in AspectME.
An ObjectOutputStream reads the field values from the written object and primi-
tive fields are written to the DataOutputStream. Objects are written recursively.
Counterwise we have an ObjectInputStream that reads objects by writing the field
values by reading them from a DataInputStream. The result is very similar to Java
SE serialization mechanism as shown in the code example below.

public Object storeAndLoad(Object obj) {
  // Write object to byte array
  ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
  ObjectOutputStream objOut = new ObjectOutputStream(byteOut);
  objOut.writeObject(obj);
  objOut.close();
  byteOut.close();
  byte[] bytes = byteOut.toByteArray();  

  // Read object from the byte array
  ByteArrayInputStream byteIn = new ByteArrayInputStream(bytes);
  ObjectInputStream objIn = new ObjectInputStream(byteIn);
  return objIn.readObject();
}

If you’re interested in the implementation of the classes you can find them in the
code examples on the AspectME home page (see References).
All that’s left is to define our aspects in an aspectme.xml file:

<?xml version=”1.0”?>
<aspectme>
   <pointcut id=”addRemoveMethods”
             expression=”execution(*
*..domain.ContactList.addContact(..)) ||
                         execution(*
*..domain.ContactList.removeContact(..))” />
   <pointcut id=”newContactList”
expression=”call(*..domain.ContactList.new())” />
   <advice id=”persist”
class=”org.aspectme.example.aspects.PersistenceAdvice” />
   <aspect advice-ref=”persist” type=”around”
pointcut-ref=”addRemoveMethods” />
   <aspect advice-ref=”persist” type=”around”
pointcut-ref=”newContactList” />
   <!-- This will add reflection information for all objects
in the specified package. -->
   <reflect include=”org.aspectme.example.contact.domain.*” />
</aspectme>

After the weaving process our application will store the ContactList object into the
record store whenever a contact is added or removed. When the application is run
again the ContactList object is loaded from the record store. The application can
still run without the persistence aspect but all contact information will be lost when
the application closes. A good example of how crosscutting concerns creates total
transparency of an application mechanism.

Summary

AspectME is a promising AOP framework that can be used to take advantage of
AOP in CLDC enabled devices. The reflection capabilities add new dimensions to
CLDC applications such as object serialization. We have seen how advices can be
built and reused over many applications since it crosscuts the concern of persist-
ence. The performance impact is acceptable when dealing with large concerns such
as persistence. The bytecode footprint increases a couple of KB but that is a small
price to pay for the increased modularity. Often the footprint becomes smaller as we
gather all copy’n’paste like infrastructure code into small advices.

Originally published in JayView.

The Problem

Java Micro Edition (Java ME) is the most ubiquitous application platform for mobile devices. However, testing Java ME applications is not a simple task. The constraints on the Virtual Machine (VM), the limited resources and the not-always-so-well-designed APIs are all contributors to this statement. The limited environment has ”forced” application developers to write their code as compact as possible. On many an occasion this has led to an unsound application design that isn’t test friendly. In a test friendly design, the collaborators of an object can easily be stubbed. Such a design is often called a testable design. There are architectural patterns such as dependency injection that can be used to achieve a testable design. Even though this is mostly used in enterprise applications, it can be used with most modern programming languages and environments.
The ability to stub collaborating objects is great when testing code. We can create
fake or ”mock” instances of our collaborating objects and set up an expected behav-
ior for them. By doing this, we can isolate the code being exercised and verify that
the behavior of the collaborating objects was met, i.e. verify that the code under test
actually did what we intended it to do. This is known as unit testing based on mock
objects. Those who are inexperienced with this kind of testing can fi nd some good
articles on the subject in the References section located at the end of this article.
In the Java SE world, there are excellent tools like JUnit and EasyMock for creat-
ing unit tests based on mock objects. Since Java ME doesn’t support refl ection, we
have lighter versions of JUnit, such as J2MEUnit, JMUnit and Mobile JUnit. As the
Connected Limited Device Confi guration (CLDC) VM doesn’t support dynamic
object creation, we can’t use EasyMock and have to write the mock objects our-
selves.
Even if you have a testable design, there are more issues that make unit testing dif-
fi cult in Java ME:

• Creating mock objects is tedious and error prone. There are tools that can help
  you generate code for your mock objects, but you have to regenerate these if you
  change your objects, otherwise you may encounter version confl icts. This is why
  dynamic frameworks like EasyMock have gained such popularity.
• Running unit tests on the target platform takes time. Even if it only takes a minute
  to install and run some tests, it may be enough to make you not want to run the
  tests every time you change your code. Running JUnit tests in Eclipse takes a cou-
  ple of seconds. Furthermore, the limited environment puts a constraint on how
  many tests you can run on your Java ME device. This forces you to split your test
  cases between several test suites, creating even longer turn-around times.
• Automation of tests is diffi cult. You’ll need a physical device attached to your
  build server to run your tests.
• The test suite setup is done manually with Java ME unit testing frameworks. Each
  time you add or remove a test, you have to update your test suite setup. This takes
  unnecessary time and is error prone.

These issues lead the Java ME developers to the darker side of testing: integration
unit testing. Integration unit testing means that you don’t fully isolate your unit un-
der test, but rather let it talk to real instances of all or some of its collaborators. There
are however some problems with integration unit testing: It catches errors too late in
the development process, it’s complex to set up, and it often causes seemingly end-
less problems when trying to manage the test data. Unit tests based on mock objects,
on the other hand, require a minimum of test data, they are written together with
your production code, and they verify that your code actually does what you want it
to do. Java SE has elegant solutions to all of the above issues. Why not use them?

Introducing MockME

For Java ME developers, there is an underlying assumption that unit tests need to be
run on the target device. This is not true. Consider a Java EE project: An enterprise
application may be targeted to run on an application server on other hardware and
JVM vendor from our development environment. The unit tests are still run in
the development environment. How does it work? The ability to ”write once, run
everywhere” is one of the greatest strengths of Java. However, any experienced Java
developer knows that this is not completely true. There can be some compatibility
issues (e.g. threading), but for unit tests this will not be a problem. We’re only testing
a small unit in a controlled setup.
Given that the above statement is true, we could run our tests in a Java SE en-
vironment and utilize all its excellent tools! This is the basic idea behind MockME;
to write unit tests for Java ME applications and run them in Java SE. So how does
it work? MockME contains empty objects for CLDC, Mobile Information Device
Profi le (MIDP), and other JSRs designed to run in Java SE. Then we use EasyMock
to create mock objects dynamically from MockME. Now, some might ask: ”Why
not create the mock objects from the classes in a wireless toolkit (WTK)”? Unfor-
tunately, these toolkits contain native methods that can’t be mocked. Even if it was
possible, EasyMock can’t mock static methods, such as RecordStore.openRecordS
tore(String,boolean). MockME solves this by delegating static method invocations
to a static delegate instance with a special method name. Let’s have a look at the
inner workings:

RecordStore.java

public class RecordStore {
  // Used to delegate static method invocations
  private static RecordStore _delegate;
  // Used to set static delegate, i.e. a mock object
  public static void setStaticInstance(RecordStore delegate) {
    _delegate = delegate;
  }
  // The static method delegates to a non-static equivalent
  public static RecordStore openRecordStore(String recordStoreName,
                                            boolean createIfNecessary)
      throws RecordStoreException,
             RecordStoreFullException,
             RecordStoreNotFoundException {
    return _delegate.static_openRecordStore(recordStoreName, createIfNeces-
sary);
  }
    // This method represent the static method and can be mocked!
    protected RecordStore static_openRecordStore(String recordStoreName,
                                                 boolean createIfNecessary)
          throws RecordStoreException,
                 RecordStoreFullException,
                 RecordStoreNotFoundException {
        return null;
    }
    // ...
}

By creating a mock object and setting the static instance, we fake the static method
invocations. No real magic here, but it’s important to make the development of Java
ME unit tests much simpler.

MockME In Action

OK, after motivating MockME, let’s look at a small example:

MessageDao.java

public class MessageDao {
  private static fi nal 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);
      }
    } fi nally {
      if (recordStore != null) {
        recordStore.closeRecordStore();
      }
    }
  }
  private byte[] encodeMessage(Message message) {
    // Convert message to bytecode
    byte[] bytes = ...;
    // Not important for the example and therefore omitted
    return bytes;
  }
}

The class above is an example of a simple Data Access Object (DAO). It allows us
to store and access messages from a record store. Now, we’d like to create a unit test
for the addMessage() method. It’s especially important to make sure that we always
close the record store after use. This should be done even if we get a RecordStore-
FullException. Let’s create test methods for both cases:

MessageDaoTest.java

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 and use the special method
    // provided by MockME to set the static instance
    recordStoreMock = createMock(RecordStore.class);
    RecordStore.setStaticInstance(recordStoreMock);
    // Create object under test
    messageDao = new MessageDao();
  }
  // Called by JUnit to clean up after each test run
  public void tearDown() {
    messageDao = null;
    recordStoreMock = null;
  }
  public void testAddMessage() throws Exception {
    // Set up expected behaviour
    byte[] expectEncMess = ”\u0004from\u0004text”.getBytes();
    expect(RecordStore.openRecordStore(”MessageDao”, true))
      .andReturn(recordStoreMock);
    expect(recordStoreMock.addRecord(aryEq(expectEncMess), eq(0), eq(10)))
      .andReturn(42);
    recordStoreMock.closeRecordStore();
    // Put the mock object in test state
    recordStoreMock.replay();
    // Executing the code we want to test
    Message message = new Message(”from”, ”text”);
    messageDao.addMessage(message);
    // Verify the behaviour
    recordStoreMock.verify(); 

    assertEquals(”Wrong message ID”, 42, message.getId());
  }
  public void testRecordStoreFull() throws Exception {
    // Set up expected behaviour
    expect(RecordStore.openRecordStore(”MessageDao”, true))
      .andReturn(recordStoreMock);
    expect(recordStoreMock.addRecord(eq(42), (byte[]) anyObject(),
                                     eq(0), eq(10)))
      .andThrow(new RecordStoreFullException());
    recordStoreMock.closeRecordStore(); 

    // Put the mock object in test state
    recordStoreMock.replay();
    // Executing the code we want to test
    try {
      Message message = new Message(”from”, ”text”);
      messageDao.addMessage(message);
      fail(”Expected exception”);
    } catch (RecordStoreFullException e) {
      assert(true); // Ok, expected
    }
    // Verify the behaviour
    recordStoreMock.verify();
  }
}

Lets look at the setUp() method. First we use EasyMock to create a mocked
RecordStore object dynamically, that the MessageDao is going to write its data to.
Then we invoke RecordStore.setStaticInstance() to mock all static methods
in RecordStore. Static method invocations will be delegated to static_<method
name>() equivalents.
Next is the test method testAddMessage(). The method starts preparing the en-
coded message and continues by setting up the expected behavior of the mock
object. You do this in EasyMock by invoking methods directly on the mock object.
In a sense, EasyMock ”records” these expected method invocations so it can com-
pare, or replay, the expectations with the actual invocations later, when the method
under test is called. If a method has a return value, you need to use a (statically
imported) expect() method. By using the andReturn() method, we can return a
mocked value.
Before executing the code we want to test, we invoke replay() to stop the mock
object from recording and set it to the replay state. All recorded method invocations
will be verifi ed from now on. After executing the code under test, we verify the
behavior by calling verify() on all mock objects. Finally, we use a standard JUnit
assert() method to assert the message ID. That’s it! The next test method uses
the same principle, except that we let EasyMock throw an exception during ad-
dRecord() to test that we really close the record store even if we get an exception. A
test that could be quite diffi cult if running in a Java ME environment. This is one ex-
ample of how to use MockME and EasyMock for unit testing Java ME applications.
Once you get the hang of it, it’s easy to unit test your Java ME code in Java SE.

Eyes On The Prize

We’ve now seen how MockME has given us the opportunity to use Java SE tools,
such as EasyMock, for Java ME unit tests. But there is so much more, for example
code coverage. A code coverage tool is used to detect what parts of your code are
executed. This is a great tool for motivating developers to write test code. A code
coverage report indicates the percentage of your code that was tested (covered),
normally indicated with a green bar of variable length. It’s highly motivating, and
fun, to see how the green bar grows. Remember that it is not the number of test cas-
es that is important, but what parts of your code are executed by your test cases.
You are not limited to the above mentioned tools. You could use any Java SE unit
testing tool or testing library. For example, there are libraries that simplify testing of
multi-threaded classes, comparing XML documents, and so on. This would not be
possible, or at least it would be very hard, if you were to use one of the traditional
Java ME testing frameworks.

Conclusion

In this article we have shown how to write true unit tests for Java ME applications.
Running the tests in a Java SE environment gives us a lot of advantages and is pos-
sible thanks to MockME. So, should we throw away all our Mobile JUnit test code?
No. It’s important to distinguish between unit tests and integration unit tests. We
have stressed the use of true unit tests in Java ME, something rarely seen in Java
ME projects. There is always a need to test parts of your application on the target
platform, but in combination with true unit tests, the integration unit tests will be
fewer and more focused on integration issues.

Magnus Robertsson and Johan Karlsson

References

Dependency Injection
Mock Objects
MockME
JUnit
EasyMock
J2MEUnit
JMUnit
Mobile JUnit

Originally published in JayView.