The problem, of course, lies in the fact that, pre-autoboxing, there was no question of an assignment to a variable of type
int throwing an NPE. For the first 87% of Java's numerical-version-life you just couldn't do it. The concept had no meaning, like the questions "what is north of the North Pole?", or "what color is up?". Or "can I borrow your copy of 'XDoclet in Action'?" (Author's note: because no one in my office has one).Pre-autoboxing, Eclipse would have flat out disallowed the assignment of an
Integer to an int. And here's the important point: Eclipse would have disallowed it, because the compiler would have disallowed it. Because you couldn't assign an object reference to a primitive type, inadvertently or advertently. It wouldn't be a legal assignment, so it wouldn't compile, so there would be no way for it to throw an NPE in production. That's what static typing is supposed to ensure.In true famed Java geek author style, though, Richards totally misses the pedagogical point when he uses as his sarcastixample the potential NPE-ness of code that deals with
String. Which is an object type. Which has since the beginning of Java time been subject to NPE's. As opposed to primitive types. Like int. Which have not. Until autoboxing rocked our world and broke static typing.I've actually been waiting for someone to snark on my (deliberately) satirical-yet-lighthearted insinuation that I rely too much on my IDE. That was the first point I took away from this whole exercise, and believe me I will be more wary in the future. I'm pretty sure I'm not the first to be burned by such an over-reliance. But in this case, even if I were using Emacs and the command line, I would still have fallen victim to this problem. The fault lies in the language, not in my reliance on any tool.
Bottom line: I don't think it should be too hard to excuse someone who, when seeing an NPE in his stack trace, doesn't leap immediately at the assignment to the
int variable.But maybe that's just me.
4 comments:
I write bytecode instrumenters so the first time we saw this NPE it got blamed on my instrumentation and it took me an embarrassingly long time to notice the unboxing. Once you get used to the notion that assigning to int can cause an NPE, it's just something you watch for and I think the overall readability is worth it in this case (even though I don't like the current trendline towards C++).
I think Java is long overdue for a nonnull (nullable would be better but far too late) type modifier. Then they could have only allowed auto-unboxing nonnull wrappers.
"Once you get used to the notion..."
That's the key, I think. This is the first time I've been bitten by this, and one of the reasons I wrote about it was to solidify the experience in my brain and have a place to reference it if it happens again. Eventually I'm sure it won't seem so surprising.
I think Java is just trying to keep up with the language Jones'es and finding that it's difficult to do so with some of the restrictions that are baked into the language (e.g., primitive vs. object impedance mismatch, lack of first-class/higher-order functions). Fortunately, there are alternatives on the horizon. I particularly like Scala these days.
The problem isn't that unboxing a null produces an exception, it is that your Java understanding was outdated. If Java had done this all along, you would have learned it and the error you encountered would be as obvious as calling toString() on a null. So, why blame autoboxing? Instead of saying "I can't believe I wasted an hour tracking down a completely obvious and sensible bug because I haven't completely absorbed new language features", you say "autoboxing is uncool".
Oh, and just so there is no doubt, I hope you don't think I was picking on you. I wasn't being personal. Your post just rubbed me the wrong way because I've seen a lot of this type of unfair criticism of Java. If you really have some technical argument against the feature, that would have been interesting to read.
@Norman: No question -- I'm still not quite used to all of Java 5's "features". And I concede a bias against them, because I think they've tended to muddy the cognitive waters around the language a bit.
I remember people complaining about inner classes in the same way when they were introduced, but now they're no big deal. People new to the language complain about blocks in Ruby, list comprehensions in Python, all of Lisp, etc. To paraphrase the immortal Garth Algar: "(We) fear change." Until we get used to it. At which point it's no longer "change".
And I did think you were picking one me. It's cool of you to come on here and state otherwise. I do think there's a technical argument to be made, though. I'll try to formulate my thoughts about that and post it in some less irritating way.
Oh, and I can't argue with your version of "autoboxing is uncool", but it would have been much too long a title for Blogger to handle. ;-)
Post a Comment