why get a warning while using the Vector's addElement()?

[iherage]

This is part of the code(JDK 1.5 ,windows xp Chinese(simplified))
....

Vector v=new Vector();
v.addElement(new Integer(7));
....

I got a warning.Because I am using a Chinese version,it perhaps means
in English its type is not checked while using the method addElement,so
it is not safe to use it.Why?Is not Integer an Object?And what is the
right way?

 

[Adam Maass]

This is part of the code(JDK 1.5 ,windows xp Chinese(simplified))
...

Vector v=new Vector();
v.addElement(new Integer(7));
...

I got a warning.Because I am using a Chinese version,it perhaps means
in English its type is not checked while using the method addElement,so
it is not safe to use it.Why?Is not Integer an Object?And what is the
right way?

In Java 5, Vector has been retrofitted for Generics. So you want:

Vector<Object> v = new Vector<Object>();
v.addElement(new Integer(7));


or maybe you want:

Vector<Integer> v = new Vector<Integer>();
....



-- Adam Maass

 

[iherage]

I read the java api doc of jdk 5.0 but it does not say anything about
it.It only says that the parameter is an element.
What about the other collections,LinkedList and ArrayList for
example?Do they have to use in this way?

 

[John C. Bollinger]

I read the java api doc of jdk 5.0 but it does not say anything about
it.It only says that the parameter is an element.
What about the other collections,LinkedList and ArrayList for
example?Do they have to use in this way?

None of them, including Vector, *have* to be used with type parameters:
the diagnostic message you received is a warning (or it is for me, when
I get it). All the Collections hierarchy in 1.5 is fitted for generics,
however, and they will all generate type safety warnings if used bare.

 

[Bill Tschumy]

None of them, including Vector, *have* to be used with type parameters:
the diagnostic message you received is a warning (or it is for me, when
I get it). All the Collections hierarchy in 1.5 is fitted for generics,
however, and they will all generate type safety warnings if used bare.

Is there a compiler option to disable these warnings? I didn't see one, but
it seems like a logical thing to exist. Otherwise the warnings would be
quite annoying if you choose not to "upgrade" your code.

 

[John C. Bollinger]

[...]

None of them, including Vector, *have* to be used with type parameters:
the diagnostic message you received is a warning (or it is for me, when
I get it). All the Collections hierarchy in 1.5 is fitted for generics,
however, and they will all generate type safety warnings if used bare.

Is there a compiler option to disable these warnings? I didn't see one, but
it seems like a logical thing to exist. Otherwise the warnings would be
quite annoying if you choose not to "upgrade" your code.

The -nowarn option ought to do it. -Xlint:-unchecked might also work,
and more specifically, but I don't actually use either of these.

 

[Dale King]

The -nowarn option ought to do it. -Xlint:-unchecked might also work,
and more specifically, but I don't actually use either of these.

I think in this case the OP probably should just use the -source 1.4
option to the compiler (which implies -target 1.4). Presumably the main
reason for not upgrading to generics is that you want to generate
classes that will run in a pre-1.5 VM. Just turning off the warnings
will not do that. By default the 1.5 compiler will generate classes that
will only run in a 1.5 VM.

Using the -source 1.4 option should not give you any warnings about
generics and will generate code that will run in any VM (assuming you
stick to only the API's available in that VM).

 

[Andrew Thompson]

Using the -source 1.4 option should not give you any warnings about
generics and will generate code that will run in any VM (assuming you
stick to only the API's available in that VM).

(Legend has it) That is not the case. I read an article
that claimed the following (roughly)

If you compile 1.1 compatible source using 1.4 with a
target of 1.1, it will produce 1.1 compatible class files -
but it might actually insert 1.4 methods in the
compilation of a '1.1 compatible' class. The end result
is the class will *load* just fine on a 1.1 VM - only to throw
NoSuchMethodErrors on what were supposedly 1.1 classes
and methods.

The article went on to state that you could only *gaurantee*
that 1.1 methods ended up in the class files by using a
1.1 rt.jar as the -bootclasspath option.

I can hunt around for it, if you're interested.
[ Though it seems straying off this thread. ]

 

[Raymond DeCampo]

(Legend has it) That is not the case. I read an article
that claimed the following (roughly)

If you compile 1.1 compatible source using 1.4 with a
target of 1.1, it will produce 1.1 compatible class files -
but it might actually insert 1.4 methods in the
compilation of a '1.1 compatible' class. The end result
is the class will *load* just fine on a 1.1 VM - only to throw
NoSuchMethodErrors on what were supposedly 1.1 classes
and methods.

The article went on to state that you could only *gaurantee*
that 1.1 methods ended up in the class files by using a
1.1 rt.jar as the -bootclasspath option.

Andrew,

That is correct and perfectly reasonably when you think about it. Why
would anyone try to stuff all the information about all the APIs in
every version of Java into the compiler? The compiler would be huge and
it is not the compiler's job to know the APIs. You tell the compiler
where the class files are that contain this information.

Ray

 

[Dale King]

(Legend has it) That is not the case. I read an article
that claimed the following (roughly)

If you compile 1.1 compatible source using 1.4 with a
target of 1.1, it will produce 1.1 compatible class files -
but it might actually insert 1.4 methods in the
compilation of a '1.1 compatible' class. The end result
is the class will *load* just fine on a 1.1 VM - only to throw
NoSuchMethodErrors on what were supposedly 1.1 classes
and methods.

Do you mean that it will allow you to call methods that were not
available until 1.4? That as Raymond points out is well known and
expected and is why I added the statement about sticking to only the
API's available in that VM.

If you mean that it in its internal bytecode it will insert calls to
methods that were not available until 1.4 even though the user did not
explicitly call them, then that would be a bug.