• Print

Developer Week in Review

Java on Macs: Good, Null Pointer Exceptions: Bad, SQL Server 2011: Coming, Firefox 4: Fast

by | @blackbearnh | +James Turner | Comments: 3 | November 17, 2010

Here’s what’s new for the trendy developer this week:

Java’s future on Apple: Slightly less in doubt

Last week, it looked like Apple was all “You’re not welcome here, Java.” In the changeable world that is Jobsland, this week Apple was offering to marry the language, reiterating their support for Java in OS X, and indicating that they would be supplying code and resources to the OpenJDK project.

As I’ve noted before, this makes sense for Apple, because it gets them out of the JVM business, and makes Oracle the one-stop shopping solution for all your JDK and JRE needs. It also means that the Mac can be added as a regression-tested target for a new version of Java, hopefully avoiding the kind of Java versioning snafus that rendered IBM’s SPSS (or is it PAWS this week?) statistics package broken for the last month or so.

Apple makes nice with Java and lets the Google Voice app hit the iPhone in the same week. Could peace in the Middle East be next?

Editorial: NPEs must die

Staying on a Java theme, probably the most common error messages I see on websites (after the all-too-common IIS MSQL database) are Java Null Pointer Exceptions (NPE). If you’re not a Java person, an NPE is what you get when you try to call a method on an object, but the variable holding the object contains null, rather than a real object.

NPEs are to Java what bad pointer references are to C. The difference is that, unlike C, an NPE in Java is usually a non-fatal event. In a web server container like Tomcat, an uncaught NPE ends up as status code 500 HTTP backtrace spam.

NPEs are a direct result of not checking the validity of arguments and data before operating on it. Too many Java programmers are lazy, and assume because an NPE doesn’t crash things, they can just let it trickle up the stack until someone catches it.

This is just plain bad coding. An NPE tells you almost nothing about what really went wrong. Instead, Java developers should check objects before invoking methods on them, and throw a more specific and meaningful runtime exception, such as an IllegalArgumentException, with details about what value was incorrect.

The same holds true for other languages, of course. It’s always a best practice to verify values external to the current context. Java developers just seem to be especially bad about it. So remember folks, trust but verify!

And speaking of MSQL

This must be my week for segues, because speaking of MSQL, Microsoft released a CTP version of SQL Server 2011 (Denali, they call it). CTP is Community Technology Preview, which is kinda Microsoftease for “beta.”

Love it or hate it, MSQL powers a lot of the web, and a new turn of SQL Server is a big deal for that part of the world that runs on 96-octane .NET fuel. Database technology is pretty much a two-horse game these days, now that Oracle owns the former third horse (MySQL.) A new SQL Server will hopefully raise the bar enough to get some new and interesting things out of Oracle’s two database projects.

Another day on the JavaScript racetrack

Probably the most commonly programmed platform these days is JavaScript on the browser. As a result, browser vendors take their JavaScript performance numbers very seriously. For a while, Chrome has been the target to beat. Ok, technically, Opera has been posting better numbers lately, but Opera has never managed to build significant market share. Let’s just say that Chrome has had the best numbers among the big 4 (IE, Firefox, Chrome, Safari).

Mozilla evidently decided not to take things lying down. The latest version of the Firefox 4 beta has turned in speed numbers the Road Runner would find respectable. How long will it take Google to respond? Or, will the new IE beta come from behind to snatch the crown of JavaScript performance? Personally, I’d prefer that Google fix Chrome so Flash doesn’t break on the Mac if you look at it funny …

That’s it for this week. Suggestions are always welcome, so please send tips or news here.

topic: Programming
  • http://zsolttorok.com Zsolt Török

    I’m all for null checks and not letting the VM throw the NPE. However, choosing between explicitly throwing a NullPointerException or an IllegalArgumentException seems to be a religious debate. It’s strange that James advocates IllegalArgumentException, although by following his train of thought you could come to the conclusion that throwing a NullPointerException would be better, since it’s “a more specific and meaningful runtime exception”.
    Joshua Bloch also suggests using NPE in these cases in Effective Java.

  • James Turner

    The thing is, an NPE is almost always the result of passing a null (or something that generates a null) into a method as an argument. So you want to throw an IllegalArgumentException, specifying exactly what argument caused the problem.

    James

  • Bruno Thomas

    I think that NPE could be treated almost with :

    • returning a value that make sense with the null input value

    • throwing explicitly (like Joshua Bloch via Zsolt Török) an NPE with detailed message

    • throwing a domain exception that heritates from NPE or IllegalStateException, or IllegalArgument or whatever makes sense to give more context/information about it

    • null object pattern for some complex objects carried a lot in the software

    • throwing like you said IllegalArgument, or IllegalState or another java exception that makes sense in the context

    • and sometimes, letting the NPE be catched by the catch all above, when it is not ambiguous

    And I must miss another possibilities.

    The thing is, when you implement a method, the possibility for an input to be null should raise questions about it, and developper should know for each case what is most adapted to the context. It makes no sense to define one strategy for all cases.

    Another point, is to learn to read stacktraces. I’m sometimes in charge of debugging production bugs, in most cases we know quickly why there was a NullPointerException when you have the stacktrace.

    cf http://devolu.lagrappe.net/les-nullpointerexception-doivent-elles-mourrir
    (sorry it is in french)