Newsgroup: it.comp.java
Titolo: comportamento strano... E N I G M A

Salve... Mi sono imbattuto in un problema assurdo. Praticamente ho creato
una serie di classi e per un motivo o per l'altro (per garantire che la
classe figlia avesse completa visibilità della classe padre) ho creato
involontariamente uno sviluppo ciclico......del tipo (vi risparmio il
codice):
la classe GestoreDiChat{} contiene:
    una istanza della classe GestoreInvioDisegni{}
    metodo mandaDisegno()
    metodo ricezioneDisegni{}
a sua volta la classe GestoreInvioDisegni{} contiene:
    un riferimento al GestoreDiChat che lo contiene (il "parent")
    un Vettore (il "disegno" da inviare)
    usa il metodo GestoreDiChat.mandaDisegno() per inviare
            il disegno tramite IOstream......
Adesso la cosa assurda è che al primo invio va tutto bene... Praticamente
GestoreInvioDisegni aggiorna il disegno, lo manda in stream tramite il
metodo del parent (mandaDisegno()) e in ricezione arriva tranquillo.
Ma quando aggiorno il Vettore dentro GestoreInvioDisegni e lo invio di
nuovo........PUF! Mi reinvia quello  non aggiornato! Assurdo! Riuscite ad
immaginare il problema? Per me sembra irrisolvibile. Dopo vari debugging ho
notato che il disegno arriva a GestoreDiChat.mandaDisegno() tranquillamente
aggiornato, ma in ricezione trovo sempre quello istanziato per la prima
volta!! E poi perchè giusto la prima volta? E' come se in streaming ci fosse
il fastasma del Vector vecchio! Mi sta facendo fondere sto problema! Grazie
per la pazienza, capisco che sia impossibile darmi una mano se non date
un'occhiata al codice...:) Ciauzzzz
ps: a complicare le cose.... se nel GestoreInvioDisegni{} creo con il metodo
clone() una COPIA del Vettore prima di mandarlo, allora mi arriva
correttamente quello AGGIORNATO. Significa che ho spezzato la catena di
riferimenti e che ho inviato correttamente l'oggetto? Vorrei aver chiara la
logica del problema... :'(
--
~\__________________________________/~
Heard melodies are sweet, but those unheard
Are sweeter; therefore, ye soft pipes, play on,
- Not to the sensual ear, but, more endear'd,
Pipe to the spirit ditties of no tone."
                 (J. Keats, "Ode on a Grecian Urn").
______________________________________

 un'occhiata al codice...:) Ciauzzzz
Effettivamente senza vedere il codice è "discretamente" difficile capire 
il problema. Così "a naso" mi verrebbe da pensare ad un errato utilizzo 
di qualche variabile membro (o statica); ad esempio (faccio per ipotesi) 
dentro qualche metodo potresti per sbaglio aver inizializzato un membro 
myObject in luogo di una variabile locale myObject. Questo tra gli altri 
è un motivo per cui io mantengo da anni la cara abitudine di utilizzare 
prefissi ( m_xxx )per le variabili membro, anche se purtoppo non rientra 
tra le convenzioni di codifica Sun.
Come soluzione purtroppo non mi viene in mente altro che un attento 
debugging... :(
HTH
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 ha scritto nel messaggio
news:42709629$0$20684$5fc...@news.tiscali.it...


 volta!!
Senza codice si possono solo fare delle ipotesi; e qui ne faccio una un po' 
banale: mettiamo che tu abbia il seguente metodo all'interno di una classe:
public void miometodo(int i)
 {i++;}
Poichè in java i tipi primitivi vengono passati per valore, e non per 
riferimento, il valore di all'interno del metodo miometodo è una sorta di 
copia, nel senso che viene incrementato il valore della variabile i creata 
all'interno di miometodo, e non quello passato.
Quindi il codice seguente:
int i=0;
System.out.println(i);
miometodo(i);
System.out.println(i);
genera, in output, il seguente:
0
0
...e non questo:
0
1
Diverso il discorso per gli oggetti, dove quello che viene passato per 
valore è l'indirizzo in memoria dove iniziano i dati, per cui ogni modifica 
apportata a tali oggetti all'interno di un metodo risulteranno effettivi 
anche al termine della sua esecuzione.
http://www.dmi.unict.it/~gallo/sitoProg2004/materiale/lucidi/Lez20.ppt#5
 

 dove sbaglia??
manda un pezzo di codice (semplificato) e forse capiremo dove sbagli (tu,
perchè se  vero che il 
runtime è teoricamente possibile che sbagli, è altrettanto improbabile
vista la descrizione, il tipo 
di errore ed il resto)
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:427118b1$0$2189$5fc...@news.tiscali.it...


 di errore ed il resto)
Vedi, sento proprio la necessità di risponderti.... E' vero, il 100% delle
volte è il programmatore a combinare i pasticci... Ma esiste anke il
programmatore a basso livello che ha creato il compilatore e le APIs di
java.... Bene, non è la prima volta che mi imbatto in situazioni paradossali
(hai mai provato ad appendere ad una JEditorPane una JScrollBar? Hai mai
visto che inspiegabilmente a volte salta la JScrollArea?). Questi si
chiamano BUG. E ne ho beccati parecchio! In ogni caso sono sicuro di aver
sbagliato io in questo caso (che codice complesso!), ma non escludo mai
problemi riguardanti bugs causati da altri programmatori (molto + bravi di
me, ma comunque "limitati").

 chiamano BUG. E ne ho beccati parecchio!
Bug nella visualizzazione video sono frequenti per ovvii motivi
architetturali. Serializzare un 
semplice oggetto fra due altri oggetti invece è un compito in cui è
difficile inserire un bug ;)
E poi una cosa che funziona la prima volta e poi non funziona più è un
tipico pattern di bug 
"utente".
Ovviamente parliamo di probabilità, e magari è veramente un bug,
mettiamola così: se dovessi 
scommettere dei soldi scommetterei sull'errore tuo. 


 ha scritto nel messaggio
news:d4rgkv$nuj$1...@news.newsland.it...
