tags:

views:

186

answers:

6

Why do I get exception called NullPointerException if in Java there is no such concept as a pointer?
Thanks

+2  A: 

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++.

paxdiablo
If only null would have been included in the type system :-/
pst
@paxidiablo so why on earth they invented final instead of using const. And if you think about it final isn't that descriptive as const is.
There is nothing we can do
Because const would define a constant. Final is slightly different to the const from C++ inasmuch as you can delay setting the final and, once set, it can't be changed. It seems to me that final is _exactly_ the right term. Once you set it, bang, that's the final value it's allowed to have.
paxdiablo
+2  A: 

Technically thats correct, it really should be called NullReferenceException

Dimitar
+1  A: 

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;
}
Daniel
@Daniel just out of curiuosity, and in what variable type you store this pointer?
There is nothing we can do
The pointer itself is an int. So on 64bit systems, the hash might be something slightly different (like the 4 upper bytes xord to the 4 lower bytes of the address).
Daniel
@Knowing it returns an int. But it is _not_ a pointer. It's a ... (wait for it) ... hashcode. Which in some JVMs is a function of the address, but it doesn't have to be. The behavior isn't specified by the JLS. And incidentally, because it's a hashcode, two objects can have identical idenityHashCode() values.I'm not going to downvote, but the last part of Daniel's answer is incorrect: it is wrong on more than one level to say that identityHashCode values are pointers.
CPerkins
A: 

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.

Cristina
A: 

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.

Amareswar
A: 

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.

daveangel