Discussions

Blogs: Autoboxing and NPE

Bookmark and Share Get thread feed

  1. Autoboxing and NPE (9 messages)

    If you are new to Java 5 and have been running into mysterious null pointer exceptions, then you may find Burt Beckwith's blog enlightening. In the entry Burt explains what he did to locate and eliminate a mysterious null pointer exception Burt was relying on autoboxing to allow him to use the primitive type int as keys in a map when he made this discovery.
    I spent a while earlier today debugging a very small block of code that was throwing a NPE. There were few options for instances that could be null, but since I was looking in the wrong place for the problem, it took longer than it should have to fix
    Autoboxing has been designed to address the inability to mix objects and primitives in the Java language. What Burt was trying to do was store primitive values in a Map. Since both the key and value pairs must be objects, primitives must be wrapped before you can save them. Prior to Java 5, this meant doing something map.put( new Integer( integerKey), value). With Java 5 auto-boxing comes to the rescue so that we can now do; map.put( integerKey, value). The magic is the compiler will add in all the stuff needed to create the wrapper.
    Under the hood when you autobox and treat an Integer as an int or vice versa, the compiler inserts a call to intValue()
    The difficulties comes when you need to map back to an integer. You may have a 0 or you may have a null. However since 0 is meant to represent both the designers had to make a choice and they choose null. The inject code to support auto-boxing looks something like this; Integer z = Integer.valueOf(5); Integer i = null; int j = i.intValue(); The result can be a hidden NPE.
    Reply to this

    Threaded Messages (9)

  2. I warned and blogged about this back in march 2004[ Go to top ]

    http://rifers.org/blogs/gbevin/2004/3/11/the_dangers_of_auto_unboxing
    Reply to this Reply to original

  3. Generics = Good, Boxing = bad...[ Go to top ]

    This is why I've used generics instead of boxing...
    Reply to this Reply to original

  4. Re: Autoboxing and NPE[ Go to top ]

    I like the idea of autoboxing, but I think the implementation in Java 5 leaves something to be desired. For instance, why doesn't the following code do what it seems like it should do? Boolean enabled; if (enabled) { System.out.println("Enabled!"); } If you run this code, you will get a NullPointerException because the Boolean property is null and autoboxing attempts to convert null to a primitive boolean. Why doesn't it just convert it to false? Similarly, why doesn't a null Integer reference simply get converted to 0 (zero)? And a null Double reference to 0d (zero double)? And a null Float reference to 0f (zero float)? And so on... This leads to some awkward code: if (enabled != null && enabled) { System.out.println("Enabled!"); } What can you do.
    Reply to this Reply to original

  5. Re: Autoboxing and NPE[ Go to top ]

    Ian, I must say I don't agree with you. It is natural to get a NPE there, since you are using a variable of a non-primitive type, which is null. You cannot expect Java to make asumptions about what the value of that variable should be. If it is null, any use of that variable, in other contexts than a comparison to another variable, is supposed to throw NPE. Secondly, I also don't agree with the Kirk's blog message. Since you are using a map, you must be aware of the fact that when you are retriving an element by a certain key, you could get a NPE, if that key doesn't exist. So the natural way of using the map should be: check first for the non-null return and then try to convert the returned value directly to a primitive type. Otherwise you get NPE, which is normal, in my opinion.
    Reply to this Reply to original

  6. Re: Autoboxing and NPE[ Go to top ]

    Ian,

    I must say I don't agree with you. It is natural to get a NPE there, since you are using a variable of a non-primitive type, which is null. You cannot expect Java to make asumptions about what the value of that variable should be. If it is null, any use of that variable, in other contexts than a comparison to another variable, is supposed to throw NPE.
    Hi Bogdan, You are right, and your reply is very close to the text in the Sun documentation on autoboxing:
    The result of all this magic is that you can largely ignore the distinction between int and Integer, with a few caveats. An Integer expression can have a null value. If your program tries to autounbox null, it will throw a NullPointerException. (Sun Java Website - Autoboxing)
    In the spirit of comparative programming philosophy, I have a Perl background, and I guess I have become used to Perl's generous interpretation of source code. It has even been described as a "DWIM" (Do What I Mean) programming language:
    As much as possible, features should do what the user expects. This concept of DWIM, or "Do What I Mean," is largely a matter of intuition. The user's experiences, language exposure, and cultural background all influence their expectations. This means that intuition varies from person to person. An English speaker won't expect the same things as a Dutch speaker, and an Ada programmer won't expect the same things as a COBOL programmer. The trick in design is to use the programmer's intuitions instead of fighting against them. A clearly defined set of rules will never match the power of a feature that "just seems right." (Perl.com - Design Philosophy)
    Food for thought. Ian -- Ian Hlavats Tarantula Consulting Inc. http://www.tarantulaconsulting.com
    Reply to this Reply to original

  7. Exceptions are usually good[ Go to top ]

    Being a developer, I think exceptions are annoying when hard to find out BUT they are better to be thrown instead of some automatic conversion ... like interpreting a null value as 0 or false or something like that... One of the best things about java is its type safety while automatically converting values from and to null (and etc) hurts the type safety very badly... and trust me solving a bug with a non type safe language is very much more troublesome as in a typesafe language... so I think we should not want things which eventually will hurt ourselves... and I think that NPE are not hidden by any means I think, its just that you check only for those things which you usually practise ... instead of everything ... :)
    Reply to this Reply to original

  8. Re: Autoboxing and NPE[ Go to top ]

    I guess if you want to be safe with autoboxed primitives in containers, and you don't like checking for nulls, you should use a container that doesn't permit null values... Hashtable is one such, although it has synchronisation overheads - perhaps there should be others? I suppose you could write your own wrapper classes, but autoboxing was supposed to avoid all that...
    Reply to this Reply to original

  9. Re: Autoboxing and NPE[ Go to top ]

    I guess if you want to be safe with autoboxed primitives in containers, and you don't like checking for nulls, you should use a container that doesn't permit null values... Hashtable is one such, although it has synchronisation overheads - perhaps there should be others? I suppose you could write your own wrapper classes, but autoboxing was supposed to avoid all that...
    You could use HashMap instead of a HashTable. HashMap is NOT syncronized. So if you dont need syncronization then HashMap works great.
    Reply to this Reply to original

  10. Problem with Autoboxing[ Go to top ]

    Hi,
    Autoboxing is a great feature provided by JAVA5 but using it blindly may result in very subtle problem which will take hours and hours to
    debug and find. to read more see the link What is the problem while using '==' in autoboxing world in Java 5 ?

     

     

    Reply to this Reply to original