Posts Tagged ‘Eclipse’

Eclipse is an excellent IDE, however some of its preferences may not be that straight-forward.

On one of my recent Java projects I had to work with a character encoding other than the default ANSI encoding.
Thus, I managed to set up the database connection properly to use the required UTF-8 encoding, as well as handle the returned data correctly as UTF-8 in the Java code.
When I tried to output some of the data, for logging purposes, in the console, the output couldn’t not be read correctly. The first thought was to double-check the source code, connection properties etc, and despite the fact that everything looked just fine, the console output still was unreadable.

After spending some time trying to find a relevant option in Eclipse, I stumbled upon the “Common” tab in the Configurations panel. And indeed this is where I found the answer to the encoding problem!

Here is what you have got to do if you are having a similar issue:

(Current setup is Eclipse Galileo – 3.5 on Mac OS X Snow Leopard)

Go to Run -> Run Configurations…

Create or select an existing configuration for your project, and switch to the “Common” tab.

Choose you preferred Console Encoding as shown on the image above!

Read Full Post »


Unit Testing verifies that the smallest bits of testable source code behave exactly as expected. Test-driven development is based on Unit Testing, and the use of automated testing frameworks.
The most popular Java testing framework is JUnit. Unfortunately JUnit cannot work in J2ME projects, since J2ME does not support Reflection. However J2MEUnit comes to the rescue, as it is based on the original JUnit source code, and it is designed to work with J2ME.
This article explains how to integrate J2MEUnit with Eclipse, and write a simple Unit test.

Setting up the environment

I am assuming that Java, WTK, Eclipse and MTJ are already installed and properly configured.
For J2MEUnit, simply download the j2meunit.jar file.

Creating a new MIDlet project

Create a new MIDlet project on Eclipse.


Since this is a “hello world” type application, give it a simple name like “MobileUnitTest”.

Use the default properties on the Target Device:


Creating a “Hello World” Midlet

Right click on the “src” folder and click on New -> Java ME MIDlet
Name it “HelloUnitWorld”, and use the “mobile.unit” as package name.

You should now see the empty auto-generated methods on the newly created MIDlet.

Let’s add some minimal code, in order to run our “Hello World” application.

1. Add a new private variable on the class with the following code:

private Display display;

2. Add the following code on the “startApp()” method:

display = Display.getDisplay(this);
String message = "Hello Unit World!";
TextBox textBox = new TextBox("HelloUnitWorld", message , 50, 0);

Run the application and you should get something like that:


Adding some testable code

We need to add some testable code for this tutorial.
So let’s create something simple, a new Java class, named “Calculator”, having the following code:

package mobile.unit;

public class Calculator {

	public int Add(int firstValue, int secondValue){
		return firstValue + secondValue;


The method “Add” accepts two integer parameters, adds them, and returns the sum as integer.

Now we are going to modify the “startApp()” MIDlet method, to output a sum result.

//String message = "Hello Unit World!";
String message = String.valueOf(new Calculator().Add(3, 4));

If we run the application again, it should display the sum of 3+4:


Adding the test code

Here comes the interesting part, adding the test code.

1. We need to reference the j2meunit.jar, which we have downloaded before.
Project -> Properties -> Java Build Path -> Add External JARs… -> Select j2meunit.jar

2. Create a new source folder named “tests”.

3. Create a new Java class on the “tests” folder with the name “CalculatorTests”, on a new package “mobile.unit.tests”.

Every test class has to import the j2meunit.framework, and extend the “TestCase”.
Moreover it should have two default new constructors.
Since there is no Reflection support, we need to manually add every test method on a “TestSuite”, and have a method that returns the “TestSuite” instance.
The test methods do not have to start with the “test” prefix, however it’s a good practice to have it.
If that sounds a bit confusing, please have a look on the complete CalculatorTests.java code:

package mobile.unit.tests;

import j2meunit.framework.*;
import mobile.unit.Calculator;

public class CalculatorTests extends TestCase {

	public CalculatorTests(){

	public CalculatorTests(String name, TestMethod method){
		super(name, method);

	public Test suite(){
		TestSuite suite = new TestSuite();
		suite.addTest(new CalculatorTests("testAdd", new TestMethod()
				{public void run(TestCase tc) {((CalculatorTests) tc).testAdd();}}));
		return suite;

	public void testAdd(){
		assertEquals(10, new Calculator().Add(5, 6));


The actual test code is contained on the “testAdd()” method.
We are trying to add 5+6, and expect a sum of 10, which is clearly going to fail.

Running the tests

Here comes the tricky part, we are going to use the j2meunit console TestRunner.
Go to Run -> Run Configurations -> Java Application -> New Configuration
Project: MobileUnitTest
Main class: j2meunit.textui.TestRunner
Arguments: mobile.unit.tests.CalculatorTests

If you fail to include the correct package on the Arguments, you are going to get an ugly error on the console:

Could not create and run test suite

If everything goes fine, the console will output:

Test Results:
Run: 1 Failures: 1 Errors: 0
There was 1 failure:
1) testAdd(mobile.unit.tests.CalculatorTests) “expected:<10> but was:<11>”

This is our expected test failure!

Let’s modify the “testAdd()” method to properly pass the test:

assertEquals(11, new Calculator().Add(5, 6));

Run it again, and get on the console:

OK (1 tests)


As I have demonstrated on this tutorial, J2MEUnit requires some effort to set up the tests, and add all required code.
However the result is really pleasant, as it gives you a fully working J2ME testing environment.
And that’s what matters most at the end day, because “Debugging sucks, Testing rocks!”.

Read Full Post »