what does null mean?

[ian bilgaen]

What does null actually mean?
For example when I check if a string is not null. (string != null).
What does this null refer to?

[Jeanne Boyarsky]

Ian,
Null means that the variable hasn't been set a value.

[S Fox]

null doesn't work in a consistent way like it does in C so it confuses me too. In java you have .isEmpty and .equals and sometimes have to use those for testing values.
I can't always remember when to use the == or .equals but java is picky about it, and your program will break in mysterious ways when using the wrong one.
You're testing whether one object IS the identical same object, or if its two different objects that just have the same value as one another.

// null string
String x;

// another null string
String n = null;

// an empty string
String s = "";

if ( s.isEmpty() ) // do stuff
if ( s.equals(someObject) ) // do stuff
if ( s != null && ! s.isEmpty() ) // do stuff

[Alyxandra Harp]

From my understanding of null, it means the variable has no value. It is not any number, not even 0.

[Henry Wong]

Alyxandra Harp wrote:From my understanding of null, it means the variable has no value. It is not any number, not even 0.

A null value is for reference variables only. If a reference variable has a value of null, it means that it is not referring to any object/instance.  Internally, of course, null has a value -- everything with a state (ie. including pointing to nothing) has a value...

Henry

[Baz Edwards]

Yep, null means it does not have any value whatsoever - not even zero or an empty String.

It's very annoying and probably one of the main downfalls of Java as a language because it means you have to check variables for null everywhere, otherwise you'll get NullPointerExceptions being thrown, which is never a good thing.

In Java 8 there has been some attempt to alleviate the pain of checking for null all the time with the "Optional" class, so for example Optional.ofNullable(myNullStringObject).orElse(""), but it's still a bit of a pain, but one you learn to live with ;)

[Junilu Lacar]

Baz Edwards wrote:
It's very annoying and probably one of the main downfalls of Java as a language because it means you have to check variables for null everywhere, otherwise you'll get NullPointerExceptions being thrown, which is never a good thing.

In Java 8 there has been some attempt to alleviate the pain ... but it's still a bit of a pain, but one you learn to live with ;)

Well, ...

When you find yourself dealing with that problem too much, then you have to look at the design. For example, if a method that declares an object reference return type like List is returning null, then you have to ask why it does that instead of returning an empty List. If it returns an Object and is returning null, you should ask if it's better to return a Null Object instead. These are just two ways you can create a better API and relieve the client code from having to check for null all the time.

[Baz Edwards]

Junilu Lacar wrote:

Baz Edwards wrote:
It's very annoying and probably one of the main downfalls of Java as a language because it means you have to check variables for null everywhere, otherwise you'll get NullPointerExceptions being thrown, which is never a good thing.

In Java 8 there has been some attempt to alleviate the pain ... but it's still a bit of a pain, but one you learn to live with ;)

Well, ...

When you find yourself dealing with that problem too much, then you have to look at the design. For example, if a method that declares an object reference return type like List is returning null, then you have to ask why it does that instead of returning an empty List. If it returns an Object and is returning null, you should ask if it's better to return a Null Object instead. These are just two ways you can create a better API and relieve the client code from having to check for null all the time.

Yeah I totally agree you should design your API's correctly so that the client doesn't have to check for null all the time, like you say, it's a good idea to return empty lists and things like that.  I'm just making the point that Java should never have been designed with the concept of null in the first place, but that's just my opinion.

[fred rosenberger]

i tend to think of variable names as label stickers you can put on things...like a box.  if the label has not been attached to a box, then it's null...there is nothing to look in.

If the label is on the box, then it is not null, but the box can still be empty.

So a String reference can be null...which means no String has been created, or the String object may have been created, bu the string itself has 0-length.

[Dave Tolls]

A zero length String is not null.
Well, unless you;re Oracle that is.

[Junilu Lacar]

Baz Edwards wrote:I'm just making the point that Java should never have been designed with the concept of null in the first place, but that's just my opinion.

Well, given that you're in very good company, that's a very valid opinion.  https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

[Jared Sachs]

I believe means nothing, like it doesn't have a value

[Garrett Boring]

Null means that the variable hasn't had a value set yet. Hope this helped!

[Nick Gonzalez]

Null means the variable references nothing, or it hasn't been assigned a value yet. When you declare a variable:

int i;

This variable is allocated a spot in memory, and how large is determined by its datatype (32 bits for int). Currently, there is nothing filling that spot in memory, hence it being null. As soon as you assign it any value:

i = 1;

The spot in memory is filled with 00001. At this point, it is no longer null.

[Junilu Lacar]

As noted previously, null is only applicable to reference variables. A primitive variable like int i cannot be assigned null. If it is a field, it will be assigned a value of 0 by default. If it's a local variable, it will simply be unassigned, it won't even be null.

[Sydney Baxter]

Null is the lack of anything. A value hasn't been assigned to a saved space, so it doesn't have anything it can output or use for any other function.

[Peter Rooke]

Null's an odd, weird, annoying, type of non type thing.  I believe its a type of non type in the java specification too!  

"Of complication, despond, and general distress; are two nulls equal? I fear both no and yes!" [Hugh Darwin; on about SQL].  

[Junilu Lacar]

Sydney Baxter wrote:Null is the lack of anything. A value hasn't been assigned to a saved space, so it doesn't have anything it can output or use for any other function.

This is misleading.

Consider this code:

public Object foo() {
    Object o;   // unassigned
    o = null;   // assigned something: null 

    // do something
    ...

   return o;
}

In practice, you can treat null as a special literal that is assignment compatible with any reference type. (per the JLS: https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.1)

Being that null is a special literal, it is a value albeit one that represents "nothing". It's a little paradoxical in that it's something that represents nothing, but it's still something. On the other hand, on line 2, the reference variable o is unassigned. That is, it has no value at all, not even null. Only after line 3 is executed will it have been assigned a value of null.  If line 3 were to be commented out thus leaving o unassigned, then the code represented by the ellipses on line 6 must definitely assign a value to o, even if it's just null in order for the code to compile. Otherwise, you'll get a compile-time error that says "variable o might not have been initialized".

[Dude Mcdudeski]

Null means a variable that can't be declared with any value. It wouldn't be zero either

[Campbell Ritchie]

Welcome to the Ranch

Afraid that isn't correct. The reserved word null means absence of an object. It cannot be assigned to a primitive datatype. Most variables assigned to null can later be reassigned to something else, i.e. a “real” object.

There is a NULL word in SQL, too, but it means something different from in Java®.

[Tim Holloway]

Four concepts worth considering:

• null
• void
• nothing
• unknown

In some languages, such as C, null is literally zero. So a null pointer is actually memory address zero, which can (and does) lead to interesting complications on machines where memory location zero has a special purpose. Fortunately, C doesn't throw NullPointerExceptions. In Java, null is a "placeholder" value that - as so many before me have noted - means that the object reference in question doesn't actually have a value.

Void, isn't null, but it does mean nothing. In the sense that a function that "returns" void doesn't return any value, not even null. On some platforms I've even been known to cast the results of a function call to void either to document that I intended to discard the result or to keep the compiler from whining. Example:

(void) memset(dest, 0, len);

Here the "memset" function would return the number of bytes cleared and I don't care, so I'm explicitly throwing it away. Actually, I do this with the C string copy and concatenation functions often.

Then there's "unknown". In Java you might adopt the convention that an unknown value should be represented by null, but that's at your option depending on need. Databases often use null for either unknown or not present, which are not the same thing and can often lead to grief.

Two of the biggest headaches in Java come from methods that return String or a collection where the returned value for an empty string/collection could either be literally an empty (zero-length) string/ empty collection or null. I'm solidly with Junilu on avoiding the use of null for something empty. The Optional feature was a useful addition to the repertoire, but it's still a kludge.

You may also see constructs like this in Java code:

if ( "stop".equals(action) ) {
 ...
}

While in English the sentence structure would be more natural as "if ( action.equals("stop"))", that will result in a NullPointerException if action is null because the base object belongs to no class and thus doesn't implement "equals()". On the other hand, it's perfectly legal to compare an object inheriting the equals() method from java.lang.Object to null, so no exception will occur.

[Campbell Ritchie]

Tim Holloway wrote:. . . Fortunately, C doesn't throw NullPointerExceptions. . . .

Is “fortunately” quite the right word there? If you abuse a null in C you are liable to get a segmentation fault, which is much harder to understand than an Exception in Java®.
NullPointerExceptions can be difficult to solve, unfortunately, because the real cause can be so very far from where the exception was thrown.

I believe that null may also be represented by 0 as the contents of a reference in Java®. Well, that is what Bruce Eckel suggests in his book. At least Java® has just about got rid of the notion that 0=false non‑0=true; in C you can use 0 or null to mean false, which you can't in Java®.

[Tim Holloway]

I'm pretty sure that zero is not the same thing as null in Java. Wait, I just checked. It's definitely verboten. However, you can assign 0 to an object of class java.lang.Object. Apparently the auto-boxer converts 0 to Integer(0) and assigns it.

Yikes!!!  

I'm afraid that "fortunately" is the operative word for C. C is used as a "high-level assembly language". The Prime Computer minicomputer systems kept their register file in the first half-dozen or so memory locations, with the Accumulator register being location 0. In systems-level programming you might actually end up coding something like "memory[0] = sysio(foo);".

That's just one case I can think of. IBM kept all sorts of important stuff in low RAM on the S/360 series and up, and that included location 0.

You may expect segmentation faults on nullpointer accesses, but I grew up on non-segmented systems. Depending on what (if any) memory-management hardware was present, you'd be lucky to get random garbage. A segment fault whose access address is 0 is pretty straightfoward by comparison.

0 In C is also the NUL character in both ASCII and EBCIDIC. Note that there's only one "L"! Java is much more type-safe. NUL, zero and null are all distinctly different and the differences are enforced at compile-type. Barring the "gotcha" I mentioned above!

[Campbell Ritchie]

Thank you. Does that mean Eckel was mistaken, or have I simply misread the book?

[Tim Holloway]

Campbell Ritchie wrote:Thank you. Does that mean Eckel was mistaken, or have I simply misread the book?

Since I haven't read the book, I don't know the context, but definitely 0 is not null in Java.

That only makes sense, since you don't know what an object reference really is. It could be a straight pointer, it could be a Macintosh-style "handle" (pointer-to-a-pointer), it could be an index into a pointer array or map. Or a base+displacement tuple - the language doesn't require any specific implementation, unlike C, where you're programming to a much less abstract level.

There's a whole raft of situations in programming where you have what I'd term a "heterogeneous result set". I don't know of any formal studies on the matter, but it's endemic.

Consider the classic simple search of an array for an integer value. There are 2 possible types of outcomes. You can either obtain the array index of the matching element (we'll assume only 1 match), OR you can return "NOT FOUND".

But "NOT FOUND" is not an index or even an integer. In simpler times, to denote NOT FOUND we'd generally return an obviously invalid index, such as -1. These days, we often dodge the issue by throwing an exception. In Java, we'll often return null, unless the method in question returns a primitive result.

So in C, the convention for "obviously invalid index" of a pointer is 0. Except where it isn't. :eek"

[Campbell Ritchie]

So that bit was mistaken. Thank you