I reported this issue to the JSR-201 comments address and got an almost immediate response (which is very encouraging). Thanks for being actually there, guys!

I think that this issue is very important and would like to collect public opinions about it. That's why I take the liberty to paste their reply and my answer.

Summarized:

• the NPE behaviour has been adopted since the JSR-201 group came to the concensus that when converting to natural default values, masked errors can potentially be introduced,
• I think that by throwing NPE exceptions, masked errors are always introduced since there's no clear indication of where to perform null checks.

With the current implementation in JDK 1.5, I actually think that auto-unboxing is useless and more error-prone that manual unboxing since you have to be sure to catch all occurrances manually and still introduce nullchecks all over the place.

There seem to be two very opposite point of views on this, with opponents and supporters for both and some gray area of things that are bound to taste or are dependent on the use-case (for instance when used in the Map null value retrieval problem). Maybe it's better to pull auto-unboxing back out as was originally planned and only perform auto-boxing.

Please contribute your opinion about this matter.

Their reply:

> Thanks for your input.  This topic was highly controversial.  The expert 
> group considered it in detail.  We sought public input and got many, 
> many responses.  They were *overwhelmingly* in favor of throwing 
> NullPointerException upon attempt to auto-unbox null.  The expert group 
> consensus independently favored this behavior, so it clearly won out.  
> While there are advantages to the other behavior (auto-unboxing null 
> returns the natural default value for the primitive type), it was 
> decided that the potential to mask real errors outweighed the advantages.

My answer:

thanks for the quick reply.

I can understand from a theoretical point of view that so many opted for the NPE since it sounds the safest. I would probably myself have opted for it when considering it in a detached way. I think however that now that the technology is actually available in beta form, people that are actually using it should speak out. You know that I got bitten so much by this already that I asked the makers of CodeGuide (JDK 1.5-capable IDE) for the possibility to disable auto-unboxing or to see a big fat red warning where they occur. I prefer to see at compile-time where a potential NPE can lurk than to get mails from customers saying something weird happened at runtime.

I'm really interested in a real-world example where the default initialization approach introduces real errors. If you're using auto-unboxing, you're also using auto-boxing, and most probably to store primitives in collections or to use them as parametrized types. There are no other real reasons to use the class counterparts of primitives. Now, if you're expecting to work with primitive types, you certainly don't expect any NPE and it's pretty normal to expect the natural default values to appear. With the current 1.5 implementation however, you have to be extremely careful with all code to make sure that you didn't miss any possibility of auto-unboxing. As you know, that's one of the biggest reason of introducing new bugs: relying on a human's ability to spot everything consistently manually. In the end, I feel that auto-unboxing doesn't buy me anything since I still need to add if-statements, except that it got a little harder to do since a lot can pass by unnoticed and it's still as bulky as before (apart from one little conversion call). Any other language that has primitives as first-class objects (which is what you're trying to simulate somehow here anyway), will using the natural default value since you're thinking about primitives, really.

I really urge you to open up this issue for debate again.

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?

Maybe this is common knowledge and everybody uses it already, but I recently discovered and started using Browser Cam. It turns out to be extremely convenient to check all your target browsers at once while creating a new web design.

Maybe it might be helpful for someone else too.