Newsgroup: it.comp.java
Titolo: JPanel, add e remove e memoria

Utilizzo una applicazione che ha come struttura un JFrame, nel quale di
volta in volta vengono caricati dei JPanel con i metodi add e remove.
Questa tecnica porta con se uno spreco di memoria, o cmq è una gestione
sbagliata delle swing?
Esiste un modo migliore per far apparire click dopo click videate diverse a
video?
Grazie.
Chiara
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

L'applicazione da te fatta purtroppo non è migliorabile di molto, per quel
che io so, daltronde la gestione della memoria di java sfrutta il
garbageCollector, che non è il massimo in quanto a gestione della memoria,
dal momento che elimina oggetti in modo quasi casuale e soltanto se non sono
utilizzati(o per meglio dire, referenziati) da un pò o se non c'è abbastanza
spazio in memoria (cosa che quasi mai avviene con i moderno calcolatori). La
cosa però potrebbe essere resa meno onerosa, e stilisticamentte più carina
se farai utilizzo delle classi virtuali, o quantomeno dell'ereditarietà;
Dichiara una classe dalla quale poi crei le altre, o per ereditarietà o per
completamento della classe astratta.
Se ti servono maggiori informazioni cerca Java MattoneDopoMattone (file pdf
o direttamente dalla rete in html) o eventualmente cerca info sulle classi
astratte e sull'ereditarietà... o se vuoi fammi sapere che ti scrivo altre
info, o magari anke degli esempi.
Ciao e fammi sapere!


 garbageCollector, che non è il massimo in quanto a gestione della memoria,
Questo esordio mi fa pensare che il mio modo di lavorare fa schifo.
Quale è il modo di procedere quando devo eseguire pannelli diversi in
successione in una applicazione java?
Sono disposta a riscrivere tutta l'applicazione se serve.




 >



...Aggiungo una nota al mio post precedente, in quanto essendo stato scritto
in vari momenti (come scritto ero un pò incasinato e spesso ero costretto ad
interrompere), ed essendo di dimensione elevata, ... insomma, volevo
puntualizzare una cosa: Per una gestione della memoria + pulita, ti conviene
inizializzare gli onj ponendoli uguale a null, e crearli (tramite new)
solamente al momento opportuno! Dopo l'utilizzo, imponili uguale a NULL,
dopodichè richiama il garbage che effettuarà la pulizia della memoria (anche
se sul garbage ci sarebbe da parlar molto,... a mio parere non è un metodo
ottimale ... ma questo c'è ... e dobbiamo tenercelo!!!).
Altro suggerimento, sarebbe quello di creare tante classi quanti sono i
Panel da utilizzare, o meglio, quanti sono i TIPI di Panel che ti servono
(anke in questo caso, se vi sono Panel con caratteristiche in comune,
utilizza le classi astratte come descritto nel post precedente), ed
inserirli al momento opportuno nella finestra come obj; Per ogni Panel
appartenente ad una classe, crea un solo obj che distruggerai e/o creerai al
momento opportuno.
In c++, si può anke utilizzare la classe astratta nella dichiarazione, (ad
esempio se devi dikiarare un obj di nome O1 appartenente alla classe myclass
derivata dalla classe myclassastratta, puoi dikiarare O1 appartenente alla
classe myclassastratta), in java anke è possibile, però l'ho testato solo
con applicazioni di poco conto (anke finestre, ma non sono sceso nei
dettagli).
In questo modo, se devi dichiarare due Panel appartenenti a due classi
diverse, ma ke derivano dalla stessa classe astratta, puoi dichiarare un
solo obj, con notevole risparmio di memoria!!!!
----------------------------------------------------------------



l'inutilità di queste pratiche nella maggioranza dei casi.
1. Explicit nulling
Explicit nulling is simply the practice of setting reference objects to 
null when you are finished with them. The idea behind nulling is that it 
assists the garbage collector by making objects unreachable earlier. Or 
at least that's the theory.
<...omissis...>
In the September 1997 "Java Developer Connection Tech Tips" column, Sun 
explained how explicit nulling was needed in very few special cases. 
Unfortunately, programmers often take this advice too far, using 
explicit nulling in the hope of helping the garbage collector. But in 
most cases, it doesn't help the garbage collector at all, and in some 
cases, it can actually hurt your program's performance.
Quindi, a parte pochissimi casi speciali veramente rari (vedi l'articolo 
citato sopra per capire quali), NON è necessario settare a null le 
variabili di tipo references dopo che sono state usate.
2. Explicit garbage collection
A third category where developers often mistakenly think they are 
helping the garbage collector is the use of System.gc(), which triggers 
a garbage collection (actually, it merely suggests that this might be a 
good time for a garbage collection). Unfortunately, System.gc() triggers 
a full collection, which includes tracing all live objects in the heap 
and sweeping and compacting the old generation. This can be a lot of 
work. In general, it is better to let the system decide when it needs to 
collect the heap, and whether or not to do a full collection. Most of 
the time, a minor collection will do the job. Worse, calls to 
System.gc() are often deeply buried where developers may be unaware of 
their presence, and where they might get triggered far more often than 
necessary. If you are concerned that your application might have hidden 
calls to System.gc() buried in libraries, you can invoke the JVM with 
the -XX:+DisableExplicitGC option to prevent calls to System.gc() and 
triggering a garbage collection.
Quindi, piuttosto che chiamare esplictamente il garbage collector,
fate invece il contrario: disabilitate le eventuali chiamate esplicite
che eventualmente ci siano utilizzando l'opzione
    -XX:+DisableExplicitGC
della Java Virtual Machine.
Quindi:
Garbage collection has come a long way in the last several years. Modern 
JVMs offer fast allocation and do their job fairly well on their own, 
with shorter garbage collection pauses than in previous JVMs. Tricks 
such as object pooling or explicit nulling, which were once considered 
sensible techniques for improving performance, are no longer necessary 
or helpful (and may even be harmful) as the cost of allocation and 
garbage collection has been reduced considerably.
Riassumendo:
    ==> Helping the garbage collector? NOT <==
- Dario

 citato sopra per capire quali), NON č necessario settare a null le

--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


e poi ne riparliamo?
Grazie.
- Dario

Ok! Andrò a leggere l'articolo! Se mi dici ke non servo porre obj a NULL,
non ribatto, ...ma la gestione della memoria del gc non è per nulla un gran
che a mio parere, conoscenza ed espeienza!
Cmqe, visto che siamo in argomento, io ho trovato il problema della
cosidetta "referenza circolare", che ho risolto proprio in questo modo! Tu
sapresti darmi altre diritte forse?
Se si, sarò davvero convinto di quel ke dici,... dando per inteso ke andrò
ovviamente a keggere l'articolo! ...ma qualunque cosa dicesse tale articolo,
tu credi ad okki kiusi? Io se trovo riscontro reale si,...altrimenti no!
Bhè, ciao ed alla prox (dopo ke avrò letto l'articolo ;-) )!!!
----------------------------------------------------------------

--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Bhè, ciao ed alla prox (dopo ke avrò letto l'articolo ;-) )!!!
Ciao
- Dario
(*) Il mio primo programma C l'ho scritto nel lontano dicembre del 1983.
       Si chiamava gossip (ho ancora il sorgente!) e faceva
       dialogare 2 o + persone connesse con diversi terminali VT100
       ad uno stesso sistema Unix. Lo schermo dei terminali era
       suddiviso in N parti e quello che veniva scritto su una
       parte di uno schermo veniva replicato su tutti gli altri schermi.
       Una chat ante-litteram!
     Sono passato a Java ormai da anni: il + vecchio programma Java
     che conservo nel mio PC è del marzo del 1996.
     Adesso uso sia Java che C# (questúltimo da due anni a questa parte).

...JAVA UN GRAN COMPILATORE, BELLISSIMO...METTE A DISPOSIZIONE IL GC, MA
ANKE LA POSSIBILITA' DI UN MINIMO DI GESTIONE MEM...SFRUTTIAMOLA, perkè il
linguaggio java può dare di + di quel ke si dice, ma non possiamo affidargli
dei compiti troppo onerosi!
Io sulla mia ultima applicazione faccio uso intensivo di referenze
circolari, ed ho notato un sensibile meglioramento utilizzando il gc in modo
"forzato"..secondo te è un caso?
...Non prendertela, premetto ke la discussione si fa interessante, in quanto
la gestione della mem di java non mi ha mai convinto + di tanto x cui se
posso migliorare le mie conoscenze sono felice ... se posso allargare i miei
orizzonti..ben venga, ma allo stato attuale ritengo ke la gestione della mem
in java andrebbe migliorata, non potrà mai essere paragonata alla gestione
ke si può avere con altri linguaggi... certo è una bellissima cosa
l'esistenza del gc
ma...ma andrebbe integrata con un controllo gestibile in modo efficace da
parte del programmatore...se poi il programmatore non è in grado di
provvedere lascerà al gc la gestione,... o se la piattaforma utilizza altri
skemi e la gestione programmata per un qualsivoglia motivo non può girare,
allora il gc dovrebbe intervenire... ma per ora guardiamo le cose in
faccia...anke l'articolo letto...
...<<<CHE DELUSIONE!!!>>>
Ho leggiukkiato l'articolo, e devo dire ke speravo, ...ero
andato su quel sito con tutta la buona intenzione di apprendere
... speravo ... ed invece mi dicono solo ke:
System.gc() non pulisce la memoria ma suggerisce solamente
al garbage di farlo... NOZIONE VEKKIA COME IL CUCCO!!!
Tutti gli utenti del gc conoscono questo, o almeno dovrebbero,
ed infatti in uno dei primo post ho scritto ke con tale "invocazione"
era atta alla pulizia della memoria tramite il garbage
ke comunque agisce in base a suoi criteri (come ogni pseudo-IA che si
rispetti)
e che quindi nessuno assicura la effettiva pulizia della mem!
...è anke vero però ke alcune versioni della JVM possiedono un gc
sviluppato e più preciso,
io questo non l'ho mai testato, ma così dicono.
In ogni caso l'altro punto di discussione è ke l'invocatre il gc
potrebbe essere oneroso per la JVM, ma in base a cosa?
Al numero di obj che deve analizzare ed eventualmente rimuovere?!
...e ci si vorrebbe fermare innanzi a questo problema?
Assurdo! A mio parere soltanto ki è abituato alla produzione di SW
tramite quei mezzucci visuali (VB, VisualC++ ...),
abituato a delegare alla makkina laparte complessa della produzione,
potrebbe avere tale mentalità,... io credo ke qualunque sia il mezzo
esistente, se esiste un motivo c'è... e se si verifica che
potrebbe portar giovamenti va utilizzato;
p.e. Premesso ke non sia il caso di utilizzare
per un qualsivoglia motivo la ricorsione, molti preferiscono il while al for
...io sono il primo fra questi,...ma se l'utilizzo del for porta vantaggi,
di stile, leggibilità o altro, E' BENE UTILIZZARLO!..Tale dicasi per il
"gc()"!
In conclusione:
...Purtroppo POTREBBE VERIFICARSI KE IL GC IGNORI
TOTALMENTE LA NOSTRA RIKIESTA DI PULIZIA MEM,
ma è l'unico mezzo ke abbiamo per pulire la stessa
e renderla nuovamente disponibile...
... SAREBBE STUPIDO NON UTILIZZARLO!!!
Ps: Io stesso alle volte non utilizzo tale metodo per gestire
memoria, preferisco la gestione tramite finalize
o se possibile tamite funzioni esterne scritte in C,...
 ma se non è possibile o troppo dispendioso?
Vorrei concludere dicendo... MA E' LECITO SFRUTTARE UN POST DI UNA TERZA
PERSONA PER INSTAURARE UN DISCORSO FRA ALTRE PERSONE?
Io frequento i newsg. da poco, e non so ... magari sarebbe il caso di
proseguire in un altro "post"...ammesso ke ci sia dell'altro da dire!... per
rispetto di ki pone domande,...altrimenti si perde il file del discorso e ki
entra non riponde + alla domanda principale... ma a noi! ;-)
Inizializzerò una discussione nominata "PROBLEMA GARBAGE"...se vuoi ... o
kiunque voglia... ;-P !
CiaoCiao!
----------------------------------------------------------------

--------------------------------
Inviato via 
http://arianna.libero.it/usenet/