Newsgroup: it.comp.java
Titolo: Dubbio sulle variabili locali final

Ho un dubbio  sulle variabili locali final quando  usate con una inner
class locale ad un metodo.
Stando alla documentazione in mio possesso la inner class può accedere
solamente alle variabili del metodo contenente che sono marcate final.
Questo dovrebbe voler  dire che il valore delle  variabili deve essere
copiato da qualche  altra parte che non sia  lo stack frame originario
o altra parte dello stack. Giusto ?
E se  è giusto, c'è  un comportamento definito o  ogni implementazione
della JVM è libera di seguire una sua strada ?
Grazie anticipatamente.
-- 
 /\            ___                [@ddress: saint (at) fsfe (dot) org]
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico 
\/		    e coltivatore diretto di software 

 della JVM è libera di seguire una sua strada ?
Credo sia un comportamento molto ben definito, anche perché oggetto di 
molti test di certificazione :)
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 molti test di certificazione :)
Lo immaginavo hehe
Io che non sono certificato non ho mai scritto una inner class
anzi ora che ricordo le scriveva il wizard del visualcafe sugli handle degli
eventi dell awt :))
N
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> della JVM è libera di seguire una sua strada ?
p> Credo sia un comportamento molto ben definito,
Mi sa di  aver formulato male la frase  originale, quindi riformulo: è
stabilito da  qualche documento  da in che  parte della  memoria venga
conservata la copia del valore  della variabile locale final oppure la
tecnica  descritta nella  pagina web  citata è  solo quello  che tutti
usano perché è il più furbo?


 usano perché è il più furbo?
Se c'è qualche documento che lo stabilisce è certamente questo:
http://java.sun.com/docs/books/vmspec/
C'è di che implementarsi una JVM perfettamente compatibile. Buona lettura :)


 
Una traccia:
"Archive: Java Platform 1.1 API and Documentation"
http://java.sun.com/products/archive/jdk/1.1/
All'interno:docs/guide/innerclasses/spec/innerclasses.doc10.html
" What are the new binary compatibility requirements for Java 1.1 classes?
...A synthetic field containing a copy of a constant v is named val$v. 
These fields are final.
All these synthetic fields are initialized by constructor parameters, 
which have the same names as the fields they initialize."
puoi verificarlo decompilando (l'ho provato con javac 1.4.0)
C'e' da dire che nelle versioni recenti delle specifiche non ne ho 
trovato menzione.
--
Marco

 writes:
p> Se c'è qualche documento che lo stabilisce è certamente questo:
p> 
http://java.sun.com/docs/books/vmspec/
Non dice se c'è o non c'è ma per lo meno restringe il campo di ricerca
:).
Grazie


>>>>> "MT" == Marco Trevisan <trevisa...@NOSPAMemail.it> writes:
MT> "Archive: Java Platform 1.1 API and Documentation"
MT> 
http://java.sun.com/products/archive/jdk/1.1/
Grazie anche a te.
Tra l'altro, per curiosità e non per dubbio, ho fatto la prova facendo
la reflection di una classe creata prova, avendo i risultati che avevi
indicato.
Questo a  parer mio  è un  chiaro indice che  da qualche  parte questo
meccanismo sia  espressamente indicato  come proprio del  linguaggio e
non  dipendente dall'implementazione,  visto che  si deve  eseguire il
bytecode di Tiziosoft sulla JVM di Caiologic...


 della JVM è libera di seguire una sua strada ?
Stai prendendo parte ad Harmony o è solo uno di quei deliri estivi da
crisi di astinenza da internet che ogni tanto colpiscono? :)
a parte gli scherzi, se non c'è sulle spec della vm non ne ho idea
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it