Imaj na umu da je Vector 'legacy' klasa, koja je naknadno uglavljena u kolekcije.
To samo po sebi nije problem, a i ne odgovara na tvoje pitanje :)
Odgovor nije jednostavan i zavisi od mnogo cega. Na primer politike i programskih standarda
tvoje firme. To nije nimalo za zapostavljanje. Licno sam odusevljen da cujem da neka firma
u Srbiji (nadam se samo da je domaca) ima i postuje sopstvene standarde.
Ako nemas takvih ogranicenja onda odgovor zavisi od verzije JDK koju koristis. U realnom
svetu je slabo verovatno da ces imati priliku da koristis uvek ono sto zelis. Ja sam radio ne
na jednom projektu za zaista velike firme (SUN, Symantec, Motorola) gde je zahtevan standard
za JDK bio veoma nizak.
Ako imas tu nesrecu da je JDK 1.1 na primer, i nemas neki izbor.
Ako to nije ogranicenje, opet bih preskocio koriscenje Vector klase.
Prednost koju neko navodi jeste da je Vector sinhronizovan. Ali ako nemas
potrebe za veoma visokim stepenom multithreading aplikacije, mozes da
koristis Collections.synchronizedCollection(Collection c).
Primeti da sam napomenuo "ako nemas potrebe za visokim stepenom
multithreadinga". Ako je to slucaj, recimo razvijas server koji treba da podrzi
veliki broj istovremenih TCP konekcije zaboravi i Vector i Collections.synchronizedCollection(Collection c).
Oba zato sto ce puci prilikom velikg broja klijenta, a Vector i zato sto su mu
performanse (bar do verzije 1.4, nisam posle probao) bile lose u slucaju da treba da
radis ista osim da dodajes nove klijente u listu.
U tom slucaju koristi java.util.concurrent (od verzije 1.5, imas originalni kod u verziji 1.4).
Ali sta god koristio uvek je odlicna ideja da razdvojis interface (List) i implementaciju. Tako
da cak i ako se zeznes uvek mozes da promenis implementaciju bez promene bilo cega drugog
u tvojoj aplikaciji.
Odlicna knjiga za razumevanje problematike je:
http://www.javaconcurrencyinpractice.com/
Pozdrav, Srdjan