Newsgroup: it.comp.java
Titolo: Vector Vs ArrayList

ragazzi sapete dirmi che differenze ci sono tra i vector e gli arraylist?
grazias...
@le 

 ragazzi sapete dirmi che differenze ci sono tra i vector e gli arraylist?
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Vector.html
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ArrayList.html
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

intendevo differenze a livello basso..nel senso...occupazione della 
memoria...velocità....
In un certo senso fanno la stessa cosa..volevo sapere chi è più 
efficiente...quando conviene usare uno e quando l'altro?
ciao
@le 

@le ha scritto:

se leggi la documentazione c'è scritto :)

> se leggi la documentazione c'è scritto :)
E se proprio non ti fidi della documentazione puoi sempre guardarti il
codice sorgente

 ciao Nicola
a proposito di concorrenza, qualcuno ha dato un'occhiata a 
java.util.concurrent e sottopackage in J2SE 5.0 ?
A me pare una cosa decisamente molto interessante, ma che rompe un po' 
la "tradizione" della concorrenza in java.


Avete ragione che sulle API c'e' scritto chiaramente
comunque se proprio Ale e' un "lazy coder" :
VEctor e' sinchronized mentre arraylist no
questo implica che conviene usare ArrayList nella stragrande maggioranza dei
casi perche' la sincronizzazione rende il vector + pesante
e' molto raro che un programmatore debba gestire la concorrenza.
ciao Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

non è raro...
pensa a due o + thread che devono modificare in base a delle operazioni un 
vettore dinamico....
potrebbe succedere che 2 thread debbano modificare contemporaneamente il 
vettore..a questo punto server un vector e nn l'arrayList!!!!! 

...

Non è affatto raro... quando stai scrivendo una servlet devi sempre
pensare a possibili problemi di concorrenza.

 pensare a possibili problemi di concorrenza.
Uso servlet dal 99
forse una o 2 volte ho dovuto sincronizzare per cachizzare qualche tabella
del db, nel qual caso uso una singleton, ma essendo in sola lettura non so
se serve manco quella
Se vi gestite voi la concorrenza in una webapp
1. imho avete sbagliato architettura
2. al 90% non siete + j2ee
Comunque e' veramente raro.
ciao Nicola


 non č raro...

...oppure usi ArrayList e gestisci la concorrenza personalmente, che
sicuramente guadagni in prestazioni
-- 
Fermiamo Scientology prima che sia troppo tardi!!!
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx/
 - 
http://www.xenu.net/
(per rispondere personalmente leva IlDitoDalCulo)

 non č raro...

Vector č una classe legacy e non andrebbe mai usata.
L'arraylist ha un wrapper sincronizzato e non c'č affatto bisogno di farlo
a mano.
In Java5 ci sono inoltre strutture molto piů sofisticate, che per esempio
supportano letture contemporanee e scritture esclusive
ciao, hth
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sicuramente guadagni in prestazioni
gia, anche poerche di solito le operazioni da isolare sono + della semplice
lVector.put


 non č raro...

Pensa che nel j2ee puro sono vietati i 3d
sai quante volte lo ho usato io il vector in vita mia , visto che lavoro in
j2ee


 Pensa che nel j2ee puro sono vietati i 3d
E' "vietato" istanziare thread da programma, ma gli application server e 
i servlet engine *sono* multithread e gli oggetti ne devono tenere conto.

 se serve manco quella
Veramente basta che sia un attributo di sessione. Escludi che arrivino 
due richieste in concorrenza?


Gia' ma la concorrenza fra 2 ejb non e' affare del programmatore
nel caso delle servlet si e' gia' detto che raramente si devono gestire
strutture dati condivise.
Usando struts pupo' succedere solo se si decide di estendere la
ActionServlet per tenere dei dati che usano tutti in memoria.
Cio' sara' chiaramente in sola lettura e la sincronizzazione normalmente e'
inutile anche qua
Comunque non voglio dire che il Vector e la sincronizzazione non servono
mai.
Dico solo che nelle applicazioni web ben fatte e j2ee non la fa un
programmataore, creando
ore di testing e difficolta' di manutenzione.
Si usa l'architettura j2ee apposta per evitare codice troppo libero.
E' chiaro poi che chi lo scrive l'appserver usera' la sincronizzazione, ma
non credo sia frequente scrivere sw di base


 non credo sia frequente scrivere sw di base
la sincronizzazione serve di solito a chi scrive codice utente, mentre chi
scrive sw di base ha bisogno di strutture molto piů sofisticate di mutex a
livello di oggetto


 strutture dati condivise.
Non mi pare si sia detto. Anzi, io ho detto che anche un comune bean in 
sessione č potenzialmente soggetto a concorrenza. E' chiaro che un bean 
non č un grosso problema, ma una collection si.



se e' in session tu dici che e' in concorrenza fra 2 chiamate dallo stesso
URL ?
la cosa e' possibile, pero' normalmente io non la gestisco perche' se un
utente si apre 2 finestre e usa una normale applicazione aziendale j2ee son
cazzi sua se non gli funziona


 banali
Allora te la metto cosi' :
se mi danno da gestire un progetto j2ee io vieto a tutti di fare thread e
scrivere syncronized
se per te e' la norma buon per te non ti correi mai a lavorare su un
progetto assieme a me
io lavoro cosi'
chissa se sbaglio io o tu che sincronizzi non so che
senza rancore, a parte i toni il dibattito e' interessante


 ciao Nicola
In realtà queste cose non credo siano molto interessanti, visto che sono
ben documentate da anni. E' interessante invece notare come siano poco
conosciute dai più, che è uno dei motivi per cui in giro si trovano tante
applicazioni poco performanti e problematiche. Fra l'altro è richiesto
sapere quali oggetti delle specifiche servlet/jsp sono threadsafe e quali
no anche per avere una semplice certificazione sun web developer! 
comunque è sempre meglio di sincronizzare il doService() o usare il
SingleThreadModel, cosa che ho visto fare relativamente spesso.


 la "tradizione" della concorrenza in java.
Il package è sempre esistito ed usatissimo in diversi middleware, solo
che ora fa parte del core ed è più integrato con tutto il resto.
Più che rompere la tradizione fornisce soluzioni più sofisticate, che
ora sono a portata di mano per tutti
uL

 forse lavoriamo su progetti di natura diversa :)
N.B. che srto parlando di progetti j2ee di grossa entita', come sono
normalmente
le applicazioni aziendali di tipo gestionale su web, campo di applicazione
tipico del j2ee
in questa situazione sono altamente convinto che difficilmente un 3d che
necessita sincronizzazione rimane j2ee
su altri tipi di progetto sono il primo ad usare tutto lo scibile


 necessita sincronizzazione rimane j2ee
vabbč, ognuno puň essere altamente convinto di quello che vuole :), cosa č
o cosa non č j2ee č un'altra questione
ricordati che una servlet viene istanziata n volte, una per servlet
definition. Se ce n'č una sola (di servlet definition), c'č dunque un solo
oggetto che risponde a *tutti* i client, ovviamente in thread diversi che
il motore crea ad hoc (o piů probabilmente prende da un pool). Nessuno ti
chiede in applicazioni J2ee "normali" di creare codice multi-threaded, ma
creare codice thread-safe (sono due cose diverse, dovresti rileggere
attentamente gli altri post) č il minimo che devi saper fare, ed č per
questo che Sun lo chiede addirittura agli aspiranti java web-programmer
con una sezione apposita nella certificazione relativa. Che purtroppo in
Italia fanno in pochi, con il risultato che un programmatore con
un'esperienza di pochi mesi su alcuni argomenti ne sa di piů di altri che
pretendono di lavorare con una tecnologia da anni: ma questo č un problema
un po' piů ampio.
Comunque evitare del tutto la questione multithread, vietando qualsiasi
cosa abbia a che vedere con i thread come fai tu, non distinguendo fra
multithread e threadsafe, puň essere visto come un modo di scansare
eventuali problemi solo se nell'architettura c'č un DB - che ti
sincronizza l'accesso ai dati - ed un fw MVC, che evita le castronerie piů
comuni.
ciao


 uL
hai mai sentito parlare di load balancing ?
Se tu usi un 3d in loadbalancing e ci scrivi dentro qualcosa, su una
macchina c'e', sull'altra no e tu sei fritto come una patata
Segue che puoi usare un 3d in sola lettura, una cache in pratica,
normalmente all'interno di un singleton.
Segue ancora che in sola lettura non serve granche' sincronizzare
eccoti dimostrato che non si usano i 3d e non serve sincronizzare


 macchina c'e', sull'altra no e tu sei fritto come una patata
In un thread non ci scrivi niente, č solo un flusso di esecuzione. 
Anche in una servlet/JSP puoi "scriverci dentro qualcosa", ed otterresti
delle race conditions senza 
che nessuno abbia usato esplicitamente dei thread, nonostante gli
espliciti divieti agli sviluppatori 
nel tuo team e senza load balancing
Anche se scrivi in sessione, e sei in LB,  su una macchina "c'č" e
sull'altra no, a meno che non usi 
un prodotto di classe enterprise che ti garantisca il session failover,
tipicamente attraverso una 
qualche forma di distribuzione dei dati di sessione (e di sincronizzazione
degli accessi). Il ns 
Application Server usa un DB totalmente distribuito, una sorta di RAID sw,
per garantire la 
persistenza (si chiama HADB) della sessione. Altri usano tecniche diverse,
come Javaspaces o 
simili. Appunto perchč il problema di "scrivere dentro qualcosa" ce l'hai
in ogni caso, volente o 
nolente, per la natura inerentemente multithread di un AS.
A meno che le tue "scritture" siano limitate al DB, sia con EJB che senza,
come scritto in un msg 
precedente, per cui e condizioni di race sono risolte dal livello di
isolamento del DB e dagli 
eventuali contesti transazionali
ciao
uL
P.S. anche Giobbe ha un limite ;)


 P.S. anche Giobbe ha un limite ;)
?


 con tutti i suoi divieti persegue come obiettivi primari.
Continui a ripetere ma evidentemente non continui ad ascoltare quello che
ti viene detto :)
J2EE sconsiglia l'uso dei thread negli EJB, ma assolutamente non vieta,
anzi praticamente OBBLIGA, 
a scrivere codice thread safe! Sono due cose diverse, non so più come
scriverlo... da cui la 
pazienza di Giobbe.
Se ti interessa sapere il vero motivo "tecnico" per cui non si possono
usare thread negli EJB, 
dipende da come tipicamente gli AS gestiscono il contesto transazionale:
questo viene passato 
attraverso i thread - di solito con un ThreadLocal - e dunque il contesto
transazionale non si 
potrebbe propagare nei thread "autogestiti"
ciao
uL


 uL
A sto punto mi tocca ringraziarti perche' mi hai comunque detto cose molto
interessanti su cui riflettero' e studiero'.
Sul fatto di programmare safe e' scontato.
Sul fatto di interpretare il j2ee in modo restrittivo il modo di operare e'
il seguente :
si parte con i divieti e le restrizioni. Poi di volta in volta assieme al
team si decide quando e come e dove inserire le parti critiche.
Se hai mai lavorato in team con persone junior e senior e soprattutto con
gente che pensa che il j2ee sia fare una jsp con ,
mettere ferre regole, senza stare almeno all'inizio a spiegare perche' e per
come, ti garantisce di partire col piede giusto. Poi si procede ad eventuali
ottimizzazioni. Un danno a volte puo' costare moltissimo andare a trovarlo;
e se si scarica sul cliente puo' creare danni di immagine irreparabili.
Se sono solo o fossi nel team della jboss, credo non ci sarebbe bisogno di
vietare un bel nulla.
P.S.
se gli stateful non sono LB sinceramente mi crolla un mondo addosso.
Praticamente non servirebbero + a nulla e l'unica sarebbe il DB ( gli entity
dei poveri diventerebbe un buon nome)
comunque a livello tecologico la cosa ha un senso perche gli appserver del
cluster dovrebbero o clonare lo stateful oppure dovrebbero forzare a
rispondere sempre lo stesso appserver, la qual cosa mi pare improbabile.
ciao Nicola


 cluster dovrebbero o clonare lo stateful
è proprio quello che alcuni fanno. Il ns invece (Sun AS 8.1 EE)
esternalizza - se si attiva il sessionfailover - lo stato dei session bean
e dell'hhtpsession in un database molto particolare che distribuisce i
dati su diverse macchine e garantisce in questo modo il 99.999% di
affidabilità. In questo modo i dati di sessione di fatto non sono in RAM
ma - in maniera trasparente - su uno speciale DB distribuito. Ovviamente
questa cosa ha un costo, quindi non va attivata solo perchè è a
disposizione!
