Newsgroup: it.comp.java
Titolo: quesito con While e String

Salve, sto creando un programma che lavora con le String.
devo esaminare una stringa per estrarne una parte (che a priori non
conosco)
So solo che in questa stringa ci sono delle precise parole pero' non
so in  che posizione ...
es.
"FUNZIONE "+funzione+" PARAMETRI "+parametri+" CLASSE "+file+" END"
per estrarre la stringa parametri provavo cosi':
StringTokenizer st = new StringTokenizer(laStringaIntera);
String estratto = "";
while (estratto != "CLASSE")
			{
				System.out.println("RS estratto: "+estratto);
				parametri = parametri +" "+estratto;
				System.out.println("RS parametri nel while: "+parametri);
				estratto = st.nextToken();
			}
pero' non funziona.. le ho provate di tutte, ma non capisco il
problema...
(sara' una domanda scema, pero' ho sempre lavorato cosi' e con questo
non funziona..)
potete aiutarmi
Grazie


se tra le parole c'e' sempre uno spazio con lo stringTokenizer (o con
lo split()) dividi tutte le parole, le metti in un array di stringhe,
o poi cherchi nell'array le parole chiave, i tuoi parametri saranno in
indice+1
Ciao Jack

 writes:
E> while (estratto != "CLASSE")
La condizione del ciclo while sarà falsa in un e solo un caso, non per
niente String ha il metodo equals()...
L'unico caso in cui si può avere che
        estratto != "CLASSE"
è quello  in cui ad  *estratto* è stato  assegnato in modo più  o meno
diretto il riferimento alla stringa "CLASSE" definita come literal nei
sorgenti,  perché  la  JVM  ottimizza l'occupazione  di  spazio  delle
stringhe costanti, quindi  alla fine anche se hai  scritto un miliardo
di volte la stringa "CLASSE" nei  sorgenti ti trovi un solo oggetto, e
quando due  variabili fanno riferimento al medesimo  oggetto allora il
confronto con l'operatore == ritorna true.
Una String il  cui valore è "CLASSE" ottenuta  in qualsiasi altro modo
sarà un oggetto diverso.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 sarà un oggetto diverso.
Ma scusa allora perche' questo metodo mi ha sempre funzionato... ed
ora no?

cmq ho risolto... ho usato la compareTo..
cmq sarei curioso di sapere perche' mi era sempre tornato...
mah.. misteri...

 writes:
E> Ma scusa allora perche' questo metodo mi ha sempre funzionato... ed
E> ora no?
Per usare un termine tecnico in uso in alcuni reparti dell'azienda per
cui lavoro(*), "Botta di culo".
La cosa funziona così.
Se definisci
   String a = "STRINGA";   
   String b = "STRINGA";
   String c = null;
succede che  il compilatore prima  e la JVM poi  riconoscono l'oggetto
"STRINGA" e quindi ad a  e b vengono assegnati riferimenti al medesimo
oggetto.
Poi ad un certo punto magari fai:
    c = b;
e c si trova assegnato un riferimento a "STRINGA", lo stesso di a e b.
Per cui
    c == a
ritorna  true, perché vengono  confrontati i  *riferimenti* e  non gli
oggetti, e visto che a, b e c fanno riferimento al _medesimo_ oggetto,
i  riferimenti sono  per  forza di  cose  uguali (la  cosa peraltro  è
spiegata nella  documentazione, almeno in  quella che ho io  :), tutta
roba con la tazzina Sun in copertina).
Se invece c'è una riga del tipo:
    String d = c + ""
cosa succede ? A verificare il contenuto di d è ancora "STRINGA".
Ma se si va a controllare
    c == d
vale false.
Cosa è  successo ?  È stata  creata una nuova  stringa (nel dettaglio:
viene allocato uno StringBuffer creato con il contenuto di c, a questo
stringbuffer viene accodata "" ed in fine viene chiamata la toString()
sullo StringBuffer),  ma questa volta non viene  fatto alcun controllo
sul fatto che ci sia già un  oggetto con il medesimo stato. Per cui in
memoria (ascii art, usare font a larghezza fissa):
a-------------+
              V 
b-------> "STRINGA"@ObjId_ABC
              ^
c-------------+
d-------> "STRINGA"@ObjId_XYZ
La  stessa cosa  accade con  qualsiasi  altra operazione  che porti  a
"STRINGA"  come  risultato,  sia   che  si  tratti  di  operazioni  di
concatenazione e suddivisione di stringhe sia che si tratti di I/O.
E> cmq sarei curioso di sapere perche' mi era sempre tornato...
E> mah.. misteri...
Nessun mistero. 
Sul perché ho  una spiegazione cattivella o per te  (che non sei stato
attento a  leggere la  documentazione che hai  studiato) o per  chi ha
scritto (male) quella documentazione.
Comunque non sei solo...
(*)Qualche anno fa:
Gian (che  come vi sarete  accorto è estremamente  diplomatico) mentre
esamina  del codice  che deve  modificare dove  trova il  test a  == b
invece di a.equals(b):
        "Ma  #@$%*, ma  come possono essere stati così ##@%$**^!
         questo codice ha funzionato finora a botta di culo!"
Lucy (programmatrice veramente in gamba ed ottima collega): 
        "Gian, basta, la devi piantare di parlare così dei tuoi
         colleghi! Devi finirla"
(Segue animato alterco)
(Il giorno dopo)
Lucy (al telefono con un altro collega):
        "Mi raccomando in quel  punto non dovete mettere uguale 
         uguale come trovate ma  usare il metodo euqals, che se 
         no, come dice Gian, funziona a botta di culo..."




Finchè non studi resteranno tanti i misteri :P
Seriamente: se tu usi delle stringhe costanti literals può capitare
che il confronto ti funzioni, perchè il compilatore java "ottimizza"
in modo da avere la stessa reference per costanti stringhe uguali. Ma
questo non toglie che sia sbagliato e che in tutte le altre condizioni
non funzioni. Insomma una questione di "fortuna".