 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2005why get a warning while using the Vector's addElement()?
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? > This is part of the code(JDK 1.5 ,windows xp Chinese(simplified)) > ... [quoted text clipped - 7 lines] > 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 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? > 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.  SignatureJohn Bollinger jobollin@indiana.edu >> 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. [quoted text clipped - 5 lines] > 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. SignatureBill Tschumy Otherwise -- Austin, TX http://www.otherwise.com [...] >>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. SignatureJohn Bollinger jobollin@indiana.edu >> 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 [quoted text clipped - 3 lines] > 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). SignatureDale King > 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. ] SignatureAndrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.LensEscapes.com/ Images that escape the mundane >>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 [quoted text clipped - 14 lines] > 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 SignatureXML is the programmer's duct tape. >>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 [quoted text clipped - 10 lines] > 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. SignatureDale King Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.