ArrayList problem

[jacov]

HI, i have a problem with an ArrayList of data: this is a snippet of my
problem:
//code begin
ArrayList data = new ArrayList;
Vector _v = returnAVector();
for (int j = 0; j < _v.size(); j++) {
data.add(_v.elementAt(j));
}
//code end

Simple....

The problem is that the arrayList contains only the first element
repetead as many times (actually the list size)
Any hint is highly welcome
Thanks

Jacov

 

[Michael Borgwardt]

HI, i have a problem with an ArrayList of data: this is a snippet of my
problem:
//code begin
ArrayList data = new ArrayList;
Vector _v = returnAVector();
for (int j = 0; j < _v.size(); j++) {
data.add(_v.elementAt(j));
}
//code end

First, the loop is unnecessary, replace it with data.addAll(_v);
But why do you copy the data anyway? If you need an ArrayList, create
one directly.

Second, the error is not in the code you posted but in the method
returnAVector(). Most likely you do not add different objects to the
Vecor but instead add the same one many times.

 

[brandon]

First, the loop is unnecessary, replace it with data.addAll(_v);
But why do you copy the data anyway? If you need an ArrayList, create
one directly.

Second, the error is not in the code you posted but in the method
returnAVector(). Most likely you do not add different objects to the
Vecor but instead add the same one many times.

Yeah, that's my conclusion too.

I created this snippet around the sample and (of course) it works fine :

//code begin

private void test()
{
ArrayList data = new ArrayList();
Vector _v = returnAVector();
for (int j = 0; j < _v.size(); j++)
{
data.add(_v.elementAt(j));
}
showResults(data);
}

private Vector returnAVector()
{
Vector v = new Vector();
v.add("111");
v.add("222");
v.add("333");
return v;
}

private void showResults(ArrayList a)
{
for (int j = 0; j < a.size(); j++)
{
System.err.println("result (" + j + ") : " + a.get(j));
}
}

//code end

Output :

result (0) : 111
result (1) : 222
result (2) : 333

 

[Joona I Palaste]

(e-mail address removed) scribbled the following:

Yeah, that's my conclusion too.

That is the only sensible diagnosis. I didn't even need to test the
above code, merely reading it told me that the for loop was OK, the
fault must be in the Vector itself.

I created this snippet around the sample and (of course) it works fine :

//code begin

private void test()
{
ArrayList data = new ArrayList();
Vector _v = returnAVector();
for (int j = 0; j < _v.size(); j++)
{
data.add(_v.elementAt(j));
}
showResults(data);
}

private Vector returnAVector()
{
Vector v = new Vector();
v.add("111");
v.add("222");
v.add("333");
return v;
}

private void showResults(ArrayList a)
{
for (int j = 0; j < a.size(); j++)
{
System.err.println("result (" + j + ") : " + a.get(j));
}
}

//code end

Output :

result (0) : 111
result (1) : 222
result (2) : 333

To the OP: How are you creating your Vector? I think you have something
like this:

Vector v = new Vector();
MyObject m = new MyObject();
m.setInt(1);
v.add(m);
m.setInt(2);
v.add(m);
m.setInt(3);
v.add(m);

Unlike some other languages, the v.add(m) call does *NOT* make a full
copy of m and insert it to the vector v, leaving the original m free
for changing. Instead, it merely adds a reference to m to the vector v,
and thus you end up with three different references to the same object.
You would have to use m = new MyObject(); before *EACH* call to
v.add(m).

 

[Thomas G. Marshall]

(e-mail address removed) scribbled the following:


That is the only sensible diagnosis. I didn't even need to test the
above code, merely reading it told me that the for loop was OK, the
fault must be in the Vector itself.









To the OP: How are you creating your Vector? I think you have
something
like this:

Vector v = new Vector();
MyObject m = new MyObject();
m.setInt(1);
v.add(m);
m.setInt(2);
v.add(m);
m.setInt(3);
v.add(m);

Unlike some other languages, the v.add(m) call does *NOT* make a full
copy of m and insert it to the vector v, leaving the original m free
for changing. Instead, it merely adds a reference to m to the vector
v,
and thus you end up with three different references to the same
object.
You would have to use m = new MyObject(); before *EACH* call to
v.add(m).

or implement Cloneable (yada yada) if there is some accumulative state
associated with the mutator, which (if the OP was doing what you suggest)
/might/ be a situation he has.

 

[jacov]

In the loop (that is necessary and inside another loop) i always create
a different instance of an object, so the strange behaviour is curious.
Yet, i tried toi return a list directly, but the problem was the same.
I suspect that this is a promlem of synchronization of ArrayList.
But i tried also with hashtable, without the expected result.
Java is a mistery sometimes

 

[Joona I Palaste]

In the loop (that is necessary and inside another loop) i always create
a different instance of an object, so the strange behaviour is curious.
Yet, i tried toi return a list directly, but the problem was the same.
I suspect that this is a promlem of synchronization of ArrayList.
But i tried also with hashtable, without the expected result.
Java is a mistery sometimes

Then the problem must lie in some other part of your code. Now comes the
time when I have to say:
POST YOUR CODE!
I can diagnose your problem much better when I can see it, instead of
having to try to read your mind.

 

[Michael Borgwardt]

In the loop (that is necessary and inside another loop) i always create
a different instance of an object, so the strange behaviour is curious.

The other common misunderstanding that causes this kind of problem is
failure to understand that Java uses pass-by-value, so an assignment
to a method parameter inside the method has no effect outside.

Yet, i tried toi return a list directly, but the problem was the same.

Yes, we told you that the problem lies not with the copying (which is
just a pointless waste of time) but with the way the list, vector,
or whatever is built.

I suspect that this is a promlem of synchronization of ArrayList.

You suspect wrong.

 

[Thomas G. Marshall]

The other common misunderstanding that causes this kind of problem is
failure to understand that Java uses pass-by-value,

Oh so good to meet another of the PBV brethren...(see the recent wars I've
had to fight in this regard in c.programming, and c.object, and c.smalltalk
(cross posted {author runs for cover} ). Such wars seem commonplace these
days, so nothing new:

http://groups.google.com/[email protected]

(I'll have to cop to the fact that jon skeet was the one who clarified the
notion for /me/ oh so long ago...someone's gonna have to hold a gun to his
head and bring him back to c.l.j.*)

FWIW, I'll bet (not much) that you've nailed the issue of the OP.


....[stomp]...

 

[Joona I Palaste]

Oh so good to meet another of the PBV brethren...(see the recent wars I've
had to fight in this regard in c.programming, and c.object, and c.smalltalk
(cross posted {author runs for cover} ). Such wars seem commonplace these
days, so nothing new:

(snip)

"PBV brethren"? I thought it was the established opinion of the entire
regularship (can I say that?) of this newsgroup that Java always passes
by value. There is no need for "PBV brethren", on the contrary, it is
more likely that there comes some sort of "PBR resistance". =)

 

[Thomas G. Marshall]

Thomas G. Marshall



(snip)

"PBV brethren"? I thought it was the established opinion of the entire
regularship (can I say that?) of this newsgroup that Java always
passes
by value. There is no need for "PBV brethren", on the contrary, it is
more likely that there comes some sort of "PBR resistance". =)

Yes, you're right. I'm just a little battle-scarred from saying this in
other ng's...

 

[Chris Uppal]

see the recent wars I've
had to fight in this regard in c.programming, and c.object, and
c.smalltalk (cross posted {author runs for cover} ). Such wars seem
commonplace these days, so nothing new:
and:

Yes, you're right. I'm just a little battle-scarred from saying this in
other ng's...

I can see how you might be feeling a little jaded. Yet you have, apparently
voluntarily, just introduced the subject of curly braces /right in the middle/
of the dynamic-typing mega-thread !

Beat's me. You must be a glutton for punishment...

;-)

-- chris

P.S. I also see Java as solely pass-by-value, but it'd be a hell of sight
easier to explain these matters if we weren't so coy about the word "pointer".

 

[Joona I Palaste]

I can see how you might be feeling a little jaded. Yet you have, apparently
voluntarily, just introduced the subject of curly braces /right in the middle/
of the dynamic-typing mega-thread !

Should he have used square brackets instead?

P.S. I also see Java as solely pass-by-value, but it'd be a hell of sight
easier to explain these matters if we weren't so coy about the word "pointer".

I agree. Java calls them "references", but what they really act like is
pointers without the pointer arithmetic. (Opaque pointers?) But when a C
or C++ programmer sees the word "reference", he/she immediately
equivocates it with the C++ reference concept, and thinks it works the
same way, just like the nuts you tighten on metal bolts and the nuts you
eat as a slight snack are the same thing.

 

[Thomas G. Marshall]

Should he have used square brackets instead?


I agree. Java calls them "references", but what they really act like
is pointers without the pointer arithmetic. (Opaque pointers?) But
when a C
or C++ programmer sees the word "reference", he/she immediately
equivocates it with the C++ reference concept, and thinks it works the
same way, just like the nuts you tighten on metal bolts and the nuts
you
eat as a slight snack are the same thing.

Well, that last metaphor is a stretch , but I have to agree.

They should have called them pointers, even though "references" is actually
technically accurate.

What's interesting, and is still without explanation, is the
/NullPointerException/ exception. As Ali G might say, wha's up wit dat? It
deserz no respek.