tags:

views:

245

answers:

7

Can an int be null in Java?

For example:

int data = check(Node root);

if ( data == null ) {
 // do something
} else {
 // do something
}

My goal is to write a function which returns an int. Said int is stored in the height of a node, and if the node is not present, it will be null, and I'll need to check that.

I am doing this for homework but this specific part is not part of the homework, it just helps me get through what I am doing.

Thanks for the comments, but it seems very few people have actually read what's under the code, I was asking how else I can accomplish this goal; it was easy to figure out that it doesn't work.

+8  A: 

No. Only object references can be null, not primitives.

Ignacio Vazquez-Abrams
It's worth mentioning the Integer class which would be a better fit if the OP wants a null value. Or he could use a negative value to indicate "not found"
Glen
then what do u do?
Use `Integer` instead.
Ignacio Vazquez-Abrams
A: 

Only references (Objects) can be null. Primitives can't.

Lol how do I delete this?

xkdkxdxc
+5  A: 

A great way to find out:

public static void main(String args[]) {
    int i = null;
}

Try to compile.

Matt Luongo
+1 great answer.
Agusti-N
Actually .. The OP already found that out himself as per the last phrase in his question: *it was easy to figure out that it doesn't work.*
BalusC
Thanks BalusC, I found out i was trying to solve the problem :)
+4  A: 

In Java, int is a primitive type and it is not considered an object. Only objects can have a null value. So the answer to your question is no, it can't be null. But it's not that simple, because there are objects that represent most primitive types.

The class Integer represents an int value, but it can hold a null value. Depending on your check method, you could be returning an int or an Integer.

This behavior is different from some more purely object oriented languages like Ruby, where even "primitive" things like ints are considered objects.

Jonathon
+2  A: 

The code won't even compile. Only an fullworthy Object can be null, like Integer. Here's a basic example to show when you can test for null:

Integer data = check(Node root);

if ( data == null ) {
 // do something
} else {
 // do something
}

On the other hand, if check() is declared to return int, it can never be null and the whole if-else block is then superfluous.

int data = check(Node root);

// do something

Autoboxing problems doesn't apply here as well when check() is declared to return int. If it had returned Integer, then you may risk NullPointerException when assigning it to an int instead of Integer. Assigning it as an Integer and using the if-else block would then indeed have been mandatory.

To learn more about autoboxing, check this Sun guide.

BalusC
Unfortunately if "check" returns an int rather than an Integer, this won't help, because the int (which won't be null) will be automatically boxed into the Integer.
Paul Tomblin
D'oh, that was just a basic example to show **when** you can test for null. On the other hand, if check is declared to return `int`, it can never be null and the whole if block is then superfluous.
BalusC
+15  A: 

int can't but Integer can. You need to be careful when unboxing null Integers since this can cause a lot of confusion and head scratching!

Brian Agnew
There are good reasons for existence of Integer class, so use it when the needs are compelling.
Blessed Geek
@h2g2java: I hope you're not thinking that being able to use them with the default collection is compelling because for stuff like HashMap<Integer,Integer> the level of waste is huge and non-compelling. Which is why Trove's TIntIntHashMap, using only primitives, runs around circle the non-compelling HashMap<Integer,Integer>.
Webinator
A: 

As @Glen mentioned in a comment, you basically have two ways around this:

  • use an "out of bound" value. For instance, if "data" can never be negative in normal use, return a negative value to indicate it's invalid.
  • Use an Integer. Just make sure the "check" method returns an Integer, and you assign it to an Integer not an int. Because if an "int" gets involved along the way, the automatic boxing and unboxing can cause problems.
Paul Tomblin