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.