NullPointerException accessing instance member of enclosing instance
Uwe Voigt
honest, I am not a Java beginner, but I am not sure about this:
Have an inner class, not static.
In its constructor it calls the super constructor which calls a method
to initialize the object. Within this method there is another call to
a method which our class has overriden. Within the overridden method
there is an access to an instance member of the enclosing class.
Here we got NullPointerException.
Is it true that objects of inner classes can access instance members
of the enclosing instance only after constructor has finished?
Thanks.
Chris Smith
Only after the superclass constructor is finished. That is, it would be
fine to write code in the constructor of the inner class itself.
Because of this problem, it's in general a bad idea to EVER use
polymorphic dispatch from within a constructor, and if you do that
anyway, to EVER access any kind of state from that polymorphically
dispatched method.
That said, the language spec is far from clear that this scenario should
throw a NullPointerException. That's an implementation artifact, and
could easily be considered a bug in the language.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Uwe Voigt
the dispatch is done within the super class API implementation which I
cannot change. I agree that this not the art of programming but I will
simply catch this NullPointerException, that btw. is also thrown from
the statement
if (<variable> != null) ;
Chris Smith <cds...@twu.net> wrote in message news:<MPG.195fcff61...@news.altopia.com>...
Mike Schilling
> > honest, I am not a Java beginner, but I am not sure about this:
> > Have an inner class, not static.
> > In its constructor it calls the super constructor which calls a method
> > to initialize the object. Within this method there is another call to
> > a method which our class has overriden. Within the overridden method
> > there is an access to an instance member of the enclosing class.
> > Here we got NullPointerException.
> > Is it true that objects of inner classes can access instance members
> > of the enclosing instance only after constructor has finished?
>
> Only after the superclass constructor is finished. That is, it would be
> fine to write code in the constructor of the inner class itself.
> Because of this problem, it's in general a bad idea to EVER use
> polymorphic dispatch from within a constructor, and if you do that
> anyway, to EVER access any kind of state from that polymorphically
> dispatched method.
>
> That said, the language spec is far from clear that this scenario should
> throw a NullPointerException. That's an implementation artifact, and
> could easily be considered a bug in the language.
The JLS is (mostly) quite explicit about the sequence of operations that
takes place during construction (section 12.5):
http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#44670
It doesn't say at what point the enclosing instances is assigned. Logically
(to me), this would take place at the beginning of step 4: "Execute the
instance initializers and instance variable initializers for this class",
after the superclass constructor is run, following the principle that the
superclass is completely constructed before any construction of the subclass
is done. This leads to the behavior Uwe is seeing.
That is, while you're right that the JLS doesn't currently define this
behavior, I strongly suspect that if and when it does, the current behavior
won't be changed.
Chris Smith
> The JLS is (mostly) quite explicit about the sequence of operations that
> takes place during construction (section 12.5):
Yes, of course.
> It doesn't say at what point the enclosing instances is assigned. Logically
> (to me), this would take place at the beginning of step 4: "Execute the
> instance initializers and instance variable initializers for this class",
> after the superclass constructor is run, following the principle that the
> superclass is completely constructed before any construction of the subclass
> is done. This leads to the behavior Uwe is seeing.
As far as I can see, that behavior only makes sense as an implementation
artifact. That is, it makes sense because you know that the reference
of an inner class to its enclosing instance is implemented as a hidden
field. In the language abstraction, that hidden field doesn't exist;
instead, an inner class simply exists, from the moment of its inception,
within the context of an accessible outer class. The
NullPointerException is entirely out of place.
> That is, while you're right that the JLS doesn't currently define this
> behavior, I strongly suspect that if and when it does, the current behavior
> won't be changed.
I also suspect that the current behavior won't be changed, because Sun
is obsessed with backward-compatibility... even in a case like this,
where there's a near-zero chance that anyone's code will be broken.
Unlike the message you're conveying, though, I think that this is rather
unfortunate. We end up with a kludge for a language feature, simply
because Sun wanted to make minimal changes to the VM when they added
inner classes in Java 1.1.