Why does this code get warning?

[ImLazy]

This code is compiled OK.

Code: Select all

import java.util.Vector;
public class Ve {
    public static void main(String[] args) {
        Vector v1 = new Vector();
        Vector v2 = (Vector)(v1.clone());
    }
}

But if I substitute all the "Vector" by "Vector<String>":

Code: Select all

import java.util.Vector;
public class Ve {
    public static void main(String[] args) {
        Vector<String> v1 = new Vector<String>();
        Vector<String> v2 = (Vector<String>)(v1.clone());
    }
}

The code gets warning. Why?

[ImLazy]

The compiler says the type of "(Vector<String>)(v1.clone())" is Object but not Vector<String>.
Why?

[Darko]

Because return type of clone() is Object - you can't change the return type of an overriden method, I think.

Just ignore the warnings (well, that's why they have those @SuppressWarnings tags now, I guess)

[ImLazy]

Sorry, I don't quite understand.

[ImLazy]

Do you mean Vector.clone() is an overriden method, so I can't change the type? But why is the first code compiled OK?

[Darko]

Something to do with type checking - I am not sure... maybe someone else can explain it.

But here's one of the reasons (I think) they introduced generics. This code gets warning in 1.5 Java. But doesn't in 1.3 (which I use for UVa):

Code: Select all

import java.util.Vector;

public class Ve {
	public static void main(String[] args) {
		Vector v1 = new Vector();
		v1.add(new Integer(1));
		String s = (String)v1.get(0);
		System.out.println(s);
	}
}

1.3 compiler does not complain at all, but you get ClassCastException when you run it. Compilers completely trusted the user, but now they are paranoid, that's why you get those warnings anytime compiler is not 100% sure about the type.

When you use your first code - 1.5 compiler gives you a warning if you try to put anything in that vector, try it. I am not quite sure why it lets you cast that way without warning, though... maybe it's holding the breath waiting for you to do something with it

I don't know if this was helpful at all.

[ImLazy]

Thank you.
Anyway, I use the second code.

[Darko]

On a different note - why do you use Vector, anyway? Why not use ArrayList?

[ImLazy]

Because in my code, I will show the Vector in JTable by invoke the constructor of JTable.
I'm not familiar with ArrayList. Could you tell me what's the difference between Vector and ArrayList? In the Java API document, it is said :"This class is roughly equivalent to Vector, except that it is unsynchronized". What means unsynchronized?

[chunyi81]

Unsynchronized, meaning accessing elements in am ArrayList is not thread safe. Correct me if I am wrong.

[Darko]

If you check the source for Vector, you will see that a few methods are synchronized. It, basically, makes Vector "thread-safe". Meaning, if you have a multi-threaded code, no two threads can access those methods at the same time.

But, for most uses, you don't need that (all that checking creates additional overhead). That's why they made ArrayList. Those two are basically synchronized and unsynchronized versions of the same thing. By "unsynchronized" they mean, for instance, if you have two threads and both start adding elements to the list, there is no guarantee what will happen.

You can synchronize ArrayList if you want to (or any Collection, for that matter). Then you lock the whole list when needed.

Same goes for Hashtable vs HashMap.

I think they kept Vector and Hashtable because Java versions have to be backward compatible. ArrayList and HashMap are supposed to be more efficient. I will paraphrase Kawigi - people usually use Vectors because either they learned Java B.C.("before Collections") or they learned Java after learning C++ STL.

Of course, in UVa Java, all you have are Vector and Hashtable