Yesterday, I talked about the IBM JVM bug I encountered with the XML Decoder.

I didn’t mention the type if the bug. In fact, it was quite similar to the bug with the XML Encoder we had a few weeks ago.

target instanceof Class  was returning false while  (target.getClass().getName().equals(Class.class.getName()))  was returning true.

This is quite strange. Moreover, it did happen only under heavy load.

Is there some issue withe the garbage collection of class definition in the AIX IBM JVM ?

A few weeks ago, I discover a bug within the IBM JVM during XML encoding with the XML encoder.

Last week, I discover an equivalent bug with the XML decoding process.

Like a few weeks ago, I decided to work around the bug by “rewriting” the decoding process. I looked at the JVM code and found that the real parser used during XML decoding was not included in the JVM source (as of JDK 1.5).

Fortunaltely, since a few month, through the OpenJDK it is possible to find more JDK related source.

I just wanted thanks to Sun to have open those source. It helped me correcting IBM JVM issues.

It’s a long time, I didn’t write a post in my blog. I just had a really heavy workload period.

Last week, I spent my whole sunday chasing a really nasty bug related to the XmlEncoder running an JVM 1.5 AIX 64bits

The symptoms where the followings, after a certain amount of time, a XML dump done using the XmlEncoder was throwing StackOverflowException. What was really strange is that the dumped object was correctly dumped a few second before and that a new dump was throwing the exception.o After some investigations, I came to the conclusion that the problem was due the PersistentDelegate used for the class (aka java_lang_Class_PersistentDelegate). I tried to bypass this default PersistentDelegate of the java.lang.Class object but then I got InvalidClassChangeError.

Eventually, I decided to rewrite the XmlEncoder and I found the issue.

In the java_lang_Class_PersistenceDelegate, there is the following code:

protected Expression instantiate(Object oldInstance, Encoder out) {        Class c = (Class)oldInstance;        // As of 1.3 it is not possible to call Class.forName("int"),        // so we have to generate different code for primitive types.        // This is needed for arrays whose subtype may be primitive.        if (c.isPrimitive()) {            Field field = null;        try {        field = ReflectionUtils.typeToClass(c).getDeclaredField("TYPE");        } catch (NoSuchFieldException ex) {                System.err.println("Unknown primitive type: " + c);            }            return new Expression(oldInstance, field, "get", new Object[]{null});        }        else if (oldInstance == String.class) {            return new Expression(oldInstance, "", "getClass", new Object[]{});        }        else if (oldInstance == Class.class) {            return new Expression(oldInstance, String.class, "getClass", new Object[]{});        }        else {            return new Expression(oldInstance, Class.class, "forName", new Object[]{c.getName()});        }    }

The issue was due to the code:

else if (oldInstance == Class.class) {

Before calling instantiate, oldInstance.toString() was returning class org.acme.Foo. However, within the instantiate method oldInstance == Class.class was returning true which for me is totally wrong.

As a workaround, I rewrited a PersistentDelegate and replace the if statement by:

else if (((Class) oldInstance).getName().equals(Class.class.getName())) {

And now it’s working properly.

It was a Sunday, I would have prefer to spend outside.

Recently, I had to develop a add-in for Outlook. Of course, I have to admit that I’m not an expert in C#. However, being used to Java, I quickly made me easy with this new language.

I just found something that makes me loosing a lot of time.

My add-in had to delete all the contacts from an Outlook contact folder. So naively, I write the following:

foreach (ContactItem contact in contactFolder.Items)
{
contact.Delete();
}

Simple isn’t it? But the result is that it doesn’t work. No compilation error, no runtime error, just that only half of the contacts were deleted. After some Google search to find why it could be wrong, I end up on the following: Working with Members of an Items Collection.

In this note, you can read that the element of a Outlook collection, should not be deleted using a classic loop. To delete them, you have to browse the collection in reverse order.

Even if I can’t understand the reason (it seems to be close to what causes a ConcurrentAccessException in Java), I found really frustrating that nothing warn you of such a behavior. For me, a good API should be implement in such a way that a normal expected behavior should at least generate exception.

To finish, here is the code that works:

for (int i = contactsFolder.Items.Count; i > 0; i --)
{
ContactItem contact = (ContactItem) contactsFolder.Items[i];
contact.Delete();
}

In 2004, Stallman warned,