Xzajo's Weblog

Wednesday May 31, 2006

Testing memory leaks with assertGC

I was talking about assertSize in one of previous entry about testing. NbTestCase class contains more useful methods. Today I will be talking about assertGC method. The assertGC method tests tries to run garbage collect with different methods and then scan if exists path to reference in memory by using insane library. Look at simple example:

public class LeakTest extends NbTestCase {
    
    public LeakTest(java.lang.String testName) {
        super(testName);
    }
    public void testLeak() {
        String obj = new String("test1");
        WeakReference ref = new WeakReference(obj);
        obj = null; 
        assertGC("pass",ref);
        obj = new String("test2");
        ref = new WeakReference(obj);
        assertGC("fails",ref);
    }
    
    public static Test suite() {
        TestSuite suite = new NbTestSuite(LeakTest.class);
        return suite;
    }
}

First asertGC passed because in JVM exists only WeakReference for object String("test1"). The second assertGC failed because the reference obj holds String("test2").

Friday May 26, 2006

XTest testing framework flash

Jiri Skrivanek updated documentation how to use XTest framework in NetBeans IDE. XTest is extension of JUnit 3.x. It was designed to help develops tests for NetBeans platform. The flash demo is available here. Updated tutorial for XTest is on this page.

Many people in NetBeans asked me why not to switch to TestNG with annotations. To tell you truth xtest already has more features than TestNG now. Xtest has also few disadvantages. It is difficult to configure it. The authors of xtest never wrote tests. Only Jiri Skrivanek, the last owner, writes tests. Maybe he is the right person who fix problems with xtest.

Why we still use Xtest for testing NetBeans? There are few reasons:

• Over 4000 already written tests. Why to rewrite them or simulate the environment?
• Ability to store results to database
• Test4u infrastructure runs daily on different platforms and JDKs
• Used for responsiveness and performance testing

Thursday May 25, 2006

NetBeans in full screen mode

Yesterday I was speaking with Stanislav Albrecht. He is working on fullscreen mode feature in NetBeans. He showed me it on Windows L&F. The feature has not finished yet. He need to implement full sreen mode feature also for others Look&Feels. But I was impressed. I use fullscreen mode in other application on my notebook. It saves workspace on my display. I can use it now also in NetBeans.

UI spec with flash demo for this feature is available on this page. Stanislav gave me a build with this feature for testing. I will show few screenshots. On the first screenshot is NetBeans in normal mode.

Two actions are highlighted in the screenshot. The first is in main menu. It shows NetBeans in full screen mode. The second is represented by icon in the right corner of window. It maximizes the window in NetBeans layout. The other windows are slided off - minimized by window sliding feature. I clicked on both actions. The result is on the screenshot below.

The main menu will be hidden in final version. This feature will be also available for application based on RCP. Developers don't need to change their applications. They only need to rebuild their applications with new NetBeans platform. The full screen action and maximize window button will be added automatically.

Tuesday May 23, 2006

Test size of your data structures in Unit Test

Petr Nejedly invented interesting tool for measuring memory usage of data structures on java heap. Name of the tool is Insane. Pages of the tools are here. It uses Java introspection to traverse all fields and references in graph of data structure. It allows to exclude traversing for specified references. Insane was integrated with NBJunit library. NBJunit is extension of Junit 3.x. It was designed in order to test NetBeans IDE. In this article I try show power of Insane library inside NBJunit.

NBTestCase class is supper class of for NetBeans test. It extends from Junit TestCase. The NBTestCase contains assertSize methods for testing size of java structures. For example we want to measure size of NumList class:

    public static class NumList {
        public int num;
        public NumList next;
    };

A instance of the class takes 16 bytes on the heap on 32bit virtual machine. A simple test for this structure can look like this:

  public void testA() {
        NumList item = new NumList();
        // 1. test one instance   
        assertSize("NumList a",16,item);
        // 2. test size of instances in collection 
        assertSize("NumList a",Collections.singleton(item),16);
        NumList item2 = new NumList();
        item.next = item2; 
        // 3. test linked structure 
        assertSize("NumList a",Collections.singleton(item),32);
        // 4. ignore the item2 references
        assertSize("NumList a",Collections.singleton(item),16,new Object[]{item2});
    }

The test passed when the size of the structure doesn't exceed the defined limit (16 or 32 bytes). Interesting is use case on line number four

assertSize("NumList a",Collections.singleton(item),16,new Object[]{item2});

The last parameter tells that the measurement won't traverse through item2 reference. It is very useful when we measure only subset of complicated structure.

The test passed. Why the instance of NumList takes 16 bytes in memory of 32bit JVM?

• 8 bytes are for object header
• 4 bytes are allocated for num variable
• 4 bytes are allocated for reference to next NumList

    public static class NumList {
        public int num;
        public int num2;
        public NumList next;
    };

We run the test again. The test fails with message:

Testcase: testA(MemoryTest):	FAILED
NumList a: leak 8 bytes  over limit of 16 bytes
  MemoryTest$NumList: 1, 24B

junit.framework.AssertionFailedError: NumList a: leak 8 bytes  over limit of 16 bytes
  MemoryTest$NumList: 1, 24B

        at org.netbeans.junit.NbTestCase.assertSize(NbTestCase.java:1108)
        at org.netbeans.junit.NbTestCase.assertSize(NbTestCase.java:1065)
        at org.netbeans.junit.NbTestCase.assertSize(NbTestCase.java:1050)
        at org.netbeans.junit.NbTestCase.assertSize(NbTestCase.java:1039)
        at MemoryTest.testA(MemoryTest.java:28)
 

Instance takes 24 bytes in memory now. How is it possible if the int type tales 4 bytes in memory? Yes it takes four bytes. The instance takes 24 bytes on heap because the size of java object is aligned to 8 bytes. So we will fix the test for new NumList version.

  public void testA() {
        NumList item = new NumList();  
        assertSize("NumList a",24,item);
        assertSize("NumList a",Collections.singleton(item),24);
        NumList item2 = new NumList();
        item.next = item2; 
        assertSize("NumList a",Collections.singleton(item),48);
        assertSize("NumList a",Collections.singleton(item),24,new Object[]{item2});
       
    }

    public static class NumList {
        public int num;
        public int num2;
        public int num3;
        public NumList next;
    };

This version does't need more memory than the previous. We can check it by running the test. Yes, the test passed now. Isn't combination of Insane ane NbJUnit great idea?

Monday May 15, 2006

TestNG over beats JUnit ?

GlassFish project quality team chose TestNG framework for testing. Why did they make the decision? They compared the both tools in this document.

It looks like war Eclipse versus NetBeans. NetBeans dominate five years ago in Java IDE's. NetBeans had few dessign problems and almost no innovation. Therefore Eclipse eclipsed NetBeans. But the situation is quite different now. There was many new features in NetBeans 5.0. Everything is in one pack (J2SE, J2EE, J2ME, profiler). The NetBeans team is focused on usability. Many 3rd party plugins are available on nbextras.org NetBeans 5.5 beta with EJB support has been released. Completely new java editor will be in NetBeans 6.0.

Back to subject TestNG versus JUnit 4. What is idea of TestNG? I think:

• Support features which are missing in JUnit
• Simple usage. Only one jar without dependencies on 3rd party libraries and simple API.

Saturday May 13, 2006

Mocking final classes with BCEL, java.lang.instrument and EasyMock

I've introduced EasyMock library in previous entry of testing category. I read in documentation of EasyMock that final methods cannot be mocked. I've found solution of this problem for testing with Jmock library. Bytecode of the class is changed before the class is loaded. The solution also works for EasyMock. I'll describe how to do it in next paragraphs.

The Byte Code Engineering Library (BCEL) library provide simple way how to navigate and change bytecode of java classes. I used this library in order to remove final flag from classes. It is only few lines by using this library.

Java.lang.instrument provides services that allow Java programming language agents to instrument programs running on the JVM. Nice article about it is here. I used java.lang.instrumnet for changing bytecode during classloading.

Example with removing final flag is below. Transf class is implementation of java.lang.instrument service. It is not difficult to add removing of final flag for methods of class to code. I created this example to demonstrate how powerful is java.lang.instrument service.

 
import java.lang.instrument.ClassFileTransformer;
import java.lang.instrument.IllegalClassFormatException;
import java.security.ProtectionDomain;
import org.apache.bcel.Constants;
import org.apache.bcel.classfile.ClassParser;
import org.apache.bcel.classfile.JavaClass;
....

public class Transf implements ClassFileTransformer {
	public byte[] transform(ClassLoader loader, 
                                String className, 
                                Class redefiningClass, 
                                ProtectionDomain domain, 
                                byte[] bytes) throws IllegalClassFormatException {
                try {
                    ClassParser parser = new ClassParser(new ByteArrayInputStream(bytes),className);
                    JavaClass clazz = parser.parse();
                    clazz.setAccessFlags(clazz.getAccessFlags() & (~Constants.ACC_FINAL ));
                    bytes = clazz.getBytes();
                    System.out.println("Transformed Class: " + className);
                } catch (ClassFormatError ex) {
                    ex.printStackTrace();
                } catch (IOException ex) {
                    ex.printStackTrace();
                }
            return bytes;
	}
}

public class SimpleMain {
	public static void premain(String agentArguments, Instrumentation instrumentation) {	
		instrumentation.addTransformer(new Transf());
	}	
}

 
Manifest-Version: 1.0 
Premain-Class: mypackage.SimpleMain

java -javaagent:classpatching.jar ...