I successfully used the PNG behaviour hack to make transparent PNG images work effortlessly under Internet Explorer. After working some days on the desigh I decided to finally integrate it in my web application.

To my surprise the behavior didn't work anymore and it took me a fairly long time to find out why. It turns out that Internet Explorer only interpretes .htc files correct when they are served with the 'text/x-component' mime-type. This isn't set up by most servlet containers, so if you intend to use these files make sure to add this to your web.xml file:

<mime-mapping>
    <extension>.htc</extension>
    <mime-type>text/x-component</mime-type>
</mime-mapping>

Omnicore releases a new stable major release of their excellent IDE: CodeGuide. Check out their unique back-in-time debugger which dramatically improves your debugging productivity and their full support for Java 1.5.

While this is a major release with lots of new features, they give free upgrade licenses from 6.1 since the release is less than 6 months old. How excellent is that!

If you're new to CodeGuide, you can learn more about its impressive features here.

JDK 1.5 provides a collection of very nice language additions and I've become an early adopter of many of them. I recently began having my doubts about auto-unboxing of reference variables though.

Consider the following class:

class AutoUnbox<T>
{
    private T   mResult;
    
    T getResult()
    {
        /* do some stuff and return a result */
        return mResult;
    }
}

and then some code that uses it:

AutoUnbox<Boolean> a = new AutoUnbox<Boolean>();
if (true == a.getResult())
{
    System.out.println("success");
}

This looks quite harmless, doesn't it? Well you have a totally invisible NullPointerException that is lurking in this code. If the getResult() method returns null, the conversion to a primitive will throw a NullPointerException. The biggest issue with this is that it happens behind the scenes. I'm used to thinking about references that might be null when I call a method upon them. As soon as I type the dot operator, my mind thinks about the context and considers if I shouldn't perform a nullcheck first. With auto-unboxing, there is nothing that indicates that you should be careful. It could literally happen anywhere.

Imho JDK 1.5 is wrong about this and instead of throwing the NPE it should return an unintialized primitive, just as null is the uninitialized value for a reference.

I mean, look at this code:

public class Uninit
{
    int test;
    boolean bool;

    public static void main(String[] args)
    {
        new Uninit().method();
    }

    public void method()
    {
        System.out.println(test);
        System.out.println(bool);
    }
}

It returns 0 and false which means that there are default values defined for unitialized primitives. To me, when thinking about unboxing a null reference to a primitive I always expected to get this 'empty' value, not a NPE.

I think I'm going to submit a bugreport to Sun about this, what do you think?