Null pointer exception problem

[Colin]

Can someone show me why I am getting a null pointer exception from my
code. Here is a much simplified version:

class A {
private Vector<MyObject> foo;

public void func1() {
B.func2(this);
}

public void add(MyObject obj) {
foo.add(obj);
}
}

class B {
public static void func2(A obj) {
while (some condition) {
MyObject myObj = new MyObject();
obj.add(myObj);
}
}
}

If you are wondering, in my real program, class B parses an XML file
and creates the objects to add to A from the file.

Thanks,
Colin

 

[SadRed]

Can someone show me why I am getting a null pointer exception from my
code. Here is a much simplified version:

class A {
private Vector<MyObject> foo;

public void func1() {
B.func2(this);
}

public void add(MyObject obj) {
foo.add(obj);
}

}

class B {
public static void func2(A obj) {
while (some condition) {
MyObject myObj = new MyObject();
obj.add(myObj);
}
}

}

If you are wondering, in my real program, class B parses an XML file
and creates the objects to add to A from the file.

Thanks,
Colin

We see no problem in your code.
--------------------------------------------
/* save and compile as A.java */
import java.util.*;

class A {
private Vector<MyObject> foo;

public A(){
foo = new Vector<MyObject>();
}

public void func1() {
B.func2(this);
}

public void add(MyObject obj) {
foo.add(obj);
}

public static void main(String[] args){
A aa = new A();
aa.func1();
}
}

class B {
public static void func2(A obj) {
boolean boo = true;

while (boo) {
MyObject myObj = new MyObject();
obj.add(myObj);
boo = false;
}
}
}

class MyObject{
}
---------------------------------------

 

[tahseen.ur.rehman]

We see no problem in your code.
Well there is a problem which you fixed by initializing "foo"
vector in the constructor.

 

[Colin]

Well there is a problem which you fixed by initializing "foo"
vector in the constructor.

::smacks forehead::

Thanks

 

[Andrew Thompson]

If you are ...

...wanting help, it is best not to leave people..

...wondering, ...

...what the heck is ..

..in my real program, ..

...instead it is best to post an SSCCE.
<http://www.physci.org/codes/sscce.html>.
Rather than forcing potential helpers to make
changes to your example code so it actually
compiles and runs. (And yes, like SadRed,
I changed that code until it would compile,
& by the time it compiled cleanly, it ran
flawlessly.)

Andrew T.

 

[Lew]

::smacks forehead::

I always feel queasy seeing

Vector<MyObject>

Why did you choose Vector over other List implementations? Better alternatives
have been around since 1998.

-- Lew

 

[al.softdev]

Can someone show me why I am getting a null pointer exception from my
code. Here is a much simplified version:

class A {
private Vector<MyObject> foo;

public void func1() {
B.func2(this);
}

public void add(MyObject obj) {
foo.add(obj);
}

}

class B {
public static void func2(A obj) {
while (some condition) {
MyObject myObj = new MyObject();
obj.add(myObj);
}
}

}

If you are wondering, in my real program, class B parses an XML file
and creates the objects to add to A from the file.

Thanks,
Colin

Colin,

Didn't read through your code, but one likely scenario of getting this
error is if you have declared Vector and did not create an instance of
Vector before it has been used.

Try Vector<> v = new Vector(); before it has been used.

Al

 

[Colin]

I always feel queasy seeing


Why did you choose Vector over other List implementations? Better alternatives
have been around since 1998.

-- Lew

I am just starting to program in Java after years of C++, so vector
was a familiar word. I would be very interested in learning about
other types of lists. Do you have a link describing or comparing the
different available types?

Thanks,
Colin

 

[Oliver Wong]

I am just starting to program in Java after years of C++, so vector
was a familiar word. I would be very interested in learning about
other types of lists. Do you have a link describing or comparing the
different available types?

http://java.sun.com/javase/6/docs/api/java/util/List.html

In Java, "List" is the name of an interface which several classes
implement (see the "all known implementing classes" list). "Vector" is the
name of a class which implements the List interface.

The basic difference between Vector and the other classes that
implement List is that historically, Vector was written before the List
interface existed. It was later retrofitted to implement that list, so you
have a lot of "duplicate" methods, like elementAt(int index) and get(int
index), the latter being part of the List API, and the former being part
of the pre-List API of Vector.

- Oliver

 

[Lew]

http://java.sun.com/javase/6/docs/api/java/util/List.html

In Java, "List" is the name of an interface which several classes
implement (see the "all known implementing classes" list). "Vector" is the
name of a class which implements the List interface.

The basic difference between Vector and the other classes that
implement List is that historically, Vector was written before the List
interface existed. It was later retrofitted to implement that list, so you
have a lot of "duplicate" methods, like elementAt(int index) and get(int
index), the latter being part of the List API, and the former being part
of the pre-List API of Vector.

Also, all the methods in Vector and Hashtable are synchronized, an overhead
not needed in thread-local contexts. Furthermore, the Collections class can
make synchronized versions of any collection.

Sun has massive tutorials about most Java stuff.
<http://java.sun.com/docs/books/tutorial/index.html>

Collections are covvered in
<http://java.sun.com/docs/books/tutorial/collections/index.html>
<http://java.sun.com/javase/6/docs/technotes/guides/collections/index.html>

You should spend lots and lots of time in the API docs, to which Oliver
already provided one link.
<http://java.sun.com/javase/6/docs/api/>
in particular
<http://java.sun.com/javase/6/docs/api/java/util/Collection.html>
and related links will help with collections.

 

[Mike Schilling]

Also, all the methods in Vector and Hashtable are synchronized, an
overhead not needed in thread-local contexts. Furthermore, the
Collections class can make synchronized versions of any collection.

And, still further, method-level synchronization of a collection is often
not terribly useful. Straightforward-looking code like

for (int i = 0; i < list.size(); i++)
{
Object o = list.get(i);
...

can fail to do the desired thing, either silently or noisily.

Hmm, this is interesting. From the javadoc for
Collection.synchronizedList()

It is imperative that the user manually synchronize on the returned list
when iterating over it:
List list = Collections.synchronizedList(new ArrayList());
...
synchronized(list) {
Iterator i = list.iterator(); // Must be in synchronized block
while (i.hasNext())
foo(i.next());
}

This strongly implies, without actually saying so, that a synchronized list
is synchronized on itself.

 

[Chris Uppal]

Also, all the methods in Vector and Hashtable are synchronized, an
overhead not needed in thread-local contexts. Furthermore, the
Collections class can make synchronized versions of any collection.

Unfortunately, that's not quite true. /Some/ of the methods in Vector and
Hashtable are synchronised, including all the methods from "classic" Vector and
Hashtable. But the methods which they gained as part of the retrofitting to
the Collections framework (the ones inherited unaltered from AbstractList and
Dictionary) are not explicitly synchronised, and are not always safe. Worse,
there is no way of telling which of the "new" methods are safe except by
inspecting the sources to java.util.*. Similarly, there is no way of telling,
just from reading code which uses a Vector or Hashtable, whether it is using
methods from the safe "classic" set or from the potentially unsafe new
Collections set.

(I'd cite examples, except that I can't remember the details off-hand, and
don't want to go grubbing around in the source to rediscover them.)

-- chris

 

[Patricia Shanahan]

Unfortunately, that's not quite true. /Some/ of the methods in Vector and
Hashtable are synchronised, including all the methods from "classic" Vector and
Hashtable. But the methods which they gained as part of the retrofitting to
the Collections framework (the ones inherited unaltered from AbstractList and
Dictionary) are not explicitly synchronised, and are not always safe. Worse,
there is no way of telling which of the "new" methods are safe except by
inspecting the sources to java.util.*. Similarly, there is no way of telling,
just from reading code which uses a Vector or Hashtable, whether it is using
methods from the safe "classic" set or from the potentially unsafe new
Collections set.

<rant>

Every library function in Sun's C library documentation is tagged with
an "MT-level" attribute indicating its multithread behavior.

To see an example, go to docs.sun.com and search for e.g. malloc.

In these terms, most of the java.util methods are either unsafe or MT-safe.

Why isn't there a corresponding Javadoc tag, with an appropriate value
for every API method?

</rant>

Patricia

 

[Lew]

Wow. Thank you for this information.

You have thrown petrol on the fire of my contempt for Vector and Hashtable.

 

[Mike Schilling]

Unfortunately, that's not quite true. /Some/ of the methods in Vector and
Hashtable are synchronised, including all the methods from "classic"
Vector and
Hashtable. But the methods which they gained as part of the retrofitting
to
the Collections framework (the ones inherited unaltered from AbstractList
and
Dictionary) are not explicitly synchronised, and are not always safe.
Worse,
there is no way of telling which of the "new" methods are safe except by
inspecting the sources to java.util.*. Similarly, there is no way of
telling,
just from reading code which uses a Vector or Hashtable, whether it is
using
methods from the safe "classic" set or from the potentially unsafe new
Collections set.

(I'd cite examples, except that I can't remember the details off-hand, and
don't want to go grubbing around in the source to rediscover them.)

Are you sure of this? I just did the requisite grubbing in the 1.5.0
sources, and the only public methods not marked "synchronized" are those
which are implemented by calling a synchronized method.

 

[Chris Uppal]

Every library function in Sun's C library documentation is tagged with
an "MT-level" attribute indicating its multithread behavior.

To see an example, go to docs.sun.com and search for e.g. malloc.

Out of curiosity, what are the "levels" of thread-safety in that convention ?
Sun's server was taking several minutes to follow each link when I looked for
the malloc() documentation, so I didn't try to find a direct statement in the
their documents.

-- chris

 

[Chris Uppal]

Are you sure of this? I just did the requisite grubbing in the 1.5.0
sources, and the only public methods not marked "synchronized" are those
which are implemented by calling a synchronized method.

I have to recant: I thought I had such an example, but now I look again, all
the (relevant) methods of AbstractList /are/ overriden in Vector.

Sorry for the false alarm.

-- chris

 

[Chris Uppal]

Wow. Thank you for this information.

Sadly, it turned out not to be information after all. My mistake.

-- chris

 

[Lew]

Sadly, it turned out not to be information after all. My mistake.

The newsgroups are perfect for this sort of exchange - I've had many erroneous
notions dashed to the rocks.

Some turned out not to be so much erroneous as approximate.

The fact that all Vector's and Hashtable's (public) methods are synchronized
is part of the argument against it. The other part you alluded to, that they
contain legacy methods that are not part of the collections framework, whose
use runs in conflict with the collections methods.

My issue isn't so much with the classes themselves as with the pedagogic
epidemic that spreads their use without proper education. I would think that
since 1998 all Java training would begin with the collections framework
classes, and teach. e.g., the List interface first and ArrayList second, with
mention of Vector relegated to an appendix in the second-semester textbook.

Apparently not so.

One should never see Vector or Hashtable or Enumeration in introductory Java
exercises.

 

[Andrew Thompson]

Chris Uppal wrote:
..

Sorry for the false alarm.

Cheers. Deeply respect your opinion. Not just for your
understanding of intricacies of matters relating to the finer
and more arcane aspects of Java and the JLS, but moreso
for your ability to recognise occasions when you may have
misunderstood what you saw. Your candour is much
appreciated (hear, at least).

I enjoy reading your posts.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200704/1