Why does Java have a "NullPointerException" when there are no pointers in Java?

Why do I g开发者_如何转开发et an exception called NullPointerException if in Java there is no such concept as a pointer?

There are no general purpose pointers in Java, that you can easily manipulate by adding and subtracting arbitrary values like in C. This can lead to all sorts of problems for those unused to them.

However, Java still needs to distinguish between an object and "no object". It's just the name of the exception that means you're trying to use an object reference that doesn't have a backing object behind it.

You could just as easily call it NoObjectException or DereferenceException, or one of a myriad of other names to minimise the possibility that people would think Java had general purpose pointers.

But NullPointerException is what the language creators opted for, probably because they were used to coding in C and/or C++.

Yes this is one of the first annoying things I learned when learning Java LOL. It really should be called NullReferenceException, NoObjectException or DereferenceException as paxdiablo mentioned. References don't even have to represented internally as pointers and you shouldn't have to care. "Most VMs including Sun's use handles, not pointers. A handle is a pointer to a pointer so who knows how they came up with using that?" Oh Microsoft's Java VM actually does use pointers rather than handles so go figure.

Technically thats correct, it really should be called NullReferenceException

Because internally object variables are pointers to those objects. However, you don't get the pointer value except by calling System.identityHashCode(object) on most JVM implementations, which returns the pointer to the object.

EDIT: You are almost all right, I was almost wrong: identityHashCode is much more complex than returning just a pointer. I just took a look at the JVM source, and they implented a few hashcode generators. However, at least in the case where hashCode (a constant? i don't know) is a constant, they return the object pointer. Here is their source for the curious:

static inline intptr_t get_next_hash(Thread * Self, oop obj) {
  intptr_t value = 0 ;
  if (hashCode == 0) {
     // This form uses an unguarded global Park-Miller RNG,
     // so it's possible for two threads to race and generate the same RNG.
     // On MP system we'll have lots of RW access to a global, so the
     // mechanism induces lots of coherency traffic.
     value = os::random() ;
  } else
  if (hashCode == 1) {
     // This variation has the property of being stable (idempotent)
     // between STW operations.  This can be useful in some of the 1-0
     // synchronization schemes.
     intptr_t addrBits = intptr_t(obj) >> 3 ;
     value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
  } else
  if (hashCode == 2) {
     value = 1 ;            // for sensitivity testing
  } else
  if (hashCode == 3) {
     value = ++GVars.hcSequence ;
  } else
  if (hashCode == 4) {
     value = intptr_t(obj) ;
  } else {
     // Marsaglia's xor-shift scheme with thread-specific state
     // This is probably the best overall implementation -- we'll
     // likely make this the default in future releases.
     unsigned t = Self->_hashStateX ;
     t ^= (t << 11) ;
     Self->_hashStateX = Self->_hashStateY ;
     Self->_hashStateY = Self->_hashStateZ ;
     Self->_hashStateZ = Self->_hashStateW ;
     unsigned v = Self->_hashStateW ;
     v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
     Self->_hashStateW = v ;
     value = v ;
  }

  value &= markOopDesc::hash_mask;
  if (value == 0) value = 0xBAD ;
  assert (value != markOopDesc::no_hash, "invariant") ;
  TEVENT (hashCode: GENERATE) ;
  return value;
}

Because all the variables(on RHS of assignment) you declare are references to some objects in heap space. If a reference is not pointing any where then on accessing of that variable throws nullpointerexception.

If you have an object with let's say a list as an attribute and you don't explicitly allocate space for it, the running program will throw you that error.

Look into a debugger (Eclipse or what not) to see what your objects holds when you don't initialize them properly and then things are going to be pretty clear.

I think it was done so that there is a notion between object that have space in the memory and those that don't.