Newsgroup: it.comp.java
Titolo: Ha senso usare "new String"?

E' da un po' che mi pongo questa domanda.
E' praticamente sempre possibile usare le stringhe senza creare
(formalmente, con new) un oggetto Stringa. Tra l'altro, ho notato che, tra i
metodi forniti dalla classe String, nessuno permette di modificare la
stringa stessa, ma le eventuali modifiche sono sempre ritornate come valore.
Quindi mi chiedo: "esiste una utilità nel creare un oggetto stringa nel
classico modo
String s = new String()
o
String s = new String("qualcosa")?
Bye, Animanera. ;)
--
Per le mie ricerche uso SOSPlanet.it
http://www.sosplanet.it
Il motore di ricerca dei motori di ricerca

String str = new String("Ciao");
č da stupidi creare un'oggetto cosě
ma se ad esempio ho un byte[] e sono sicuro che rappresenta una stringa...
String str = new String(myByteArray);
prova a compilare questo esempio
public class Prova{
	public Prova(){
		byte[]frase = new byte[]{
			86, 101, 100, 105, 44, 32, 117, 110, 32, 115, 101, 110,
			115, 111, 32, 99, 101, 32, 108, 39, 104, 97, 33, 33, 33};
		System.out.println(new String(frase));
	}
	public static void main (String[]args){
		new Prova();
		}
	}
--------------------------------
Inviato via 
http://usenet.libero.it

 stringa stessa, ma le eventuali modifiche sono sempre ritornate come
valore.
Per modificare una stringa puoi usare la classe StringBuffer.
--
Antonio Pelleriti
Brainbench Java Master: score 4.34,
higher than 99% of all previous test takers.

 stringa... String str = new String(myByteArray);
Non e' la stessa cosa chiesta, dato che stai indicando un costruttore
diverso.
Secondo me il confronto va fatto su un codice tipo il seguente:
(versione 1)
String s1 = "Ciao";
String s2 = "Ciao";
(versione 2)
String s1 = new String("Ciao");
String s2 = new String("Ciao");
I due esempi fanno due cose diverse!
Infatti, nella (versione 1) avremo un'unico oggetto String, che vale
"Ciao", e le due variabili s1 ed s2 conterranno quindi lo stesso valore:
il reference a tale oggetto.
Nella (versione 2), avremo due oggetti distinti ed i reference presenti
nelle due variabili saranno diversi.
Ora bisogna chiedersi se questo comportamento ci interessa, serve, etc...
Ovviamente, dato che gli oggetti stringa sono immutabili, per tutte le
operazioni guidate da confronti per valore (usando equals, per capirci)
su tali oggetti e' indifferente quale dei due metodi e' stato usato.
Quindi, in tale contesto, il metodo della (versione 1) e' migliore, dato
che evita un'operazione dispendiosa come la creazione di un nuovo
oggetto.
Nel caso in cui, invece, si utilizzino i reference per effettuare i
confronti e' indispensabile che le stringhe vengano create come con la
(versione 2).
Ad esempio, supponiamo di dover gestire un'indice, in cui le chiavi sono
di tipo String, ma siano possibili delle chiavi doppie. In questo
contesto, la comparazione delle chiavi per valore non ha significato,
mentre ne ha quello per reference (ovviamente supponendo di avere il modo
di recuperare le chiavi corrette...lo so anch'io che sarebbe stato meglio
costruire un'oggetto Chiave, con un attributo String, etc....e' solo
un'esempio)
-- 
Lucio Benfante
Brainbench MVP for Java 1
http://www.brainbench.com
MyTranscript: 
http://www.brainbench.com/transcript.jsp?pid=167064

 mantenuto (visto che non e' deprecato). Che stupidi in Sun! :-)
E' semplicemente una forma di costruttore per copia.
Hai una string s e ne vuoi fare una copia s1 = new String(s)
Il fatto che nell'esempio s sia un (o una) literal non cambia il 
significato, sempre una stringa è.
Questo costruttore lo utilizzo spesso quando voglio assicurarmi che un 
parametro passatomi non sia null, infatti new String(s) dove s è null 
lancia una bella NullPointerException.
Ciao
-- 
Fabio Ambrosanio
/quousque tandem/

 
...d'accordo che l'ironia era sottile...capisco anche che lo stress in
questi giorni e' tanto....ma non capire quando uno sta scherzando!
(esplicitandolo inoltre con le faccine) :-)
(tanto per essere piu' espliciti...sto scherzando!!...non ho intenzione
di offendere nessuno, quindi niente flames, grazie.)


 
Ho semplicemente usato l'ultimo post (il tuo) per rispondere al quesito 
iniziale. Stop.


 č da stupidi creare un'oggetto cosě
Uh? Quando scrivi str = "Ciao" stai semplicemente scrivendo 
un'abbreviazione per str= new String("Ciao")...
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

Bye, Animanera. ;)
String s = new String("qualcosa") e String s = "qualcosa" sono
semanticamente equivalenti.
Viene ovviamente mantenuta anche la possibilità di instanziare
l'oggetto nel modo "tradizionale", non avrebbe senso il contrario.
Umberto

il reference a tale oggetto.
???
Per quanto mi riguarda, mi sembrava di aver letto da qualche parte che
l'esempio sopra citato, se seguito da un s1==s2, poteva generare sia un true
che un false a seconda se il compilatore ottimizzava o meno le costanti
stringa generando un unico oggetto per ogni costante. Quindi,
fondamentalmente, erano diverse (se risultavano uguali, era solo per puro
caso).
Qual'è la giusta interpretazione?
Bye, Animanera. :)

 
Direi proprio di no.Guarda l'altro mio post.


 
Secondo me la giusta interpretazione la si da' leggendo la Java Language
Specification:
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#229653
Quindi per ogni String litteral esiste un unico oggetto String.


 costanti stringa generando un unico oggetto per ogni costante.
Mai sentito.
s1 == s2 deve restituire sempre true.
come anche
s1.equals( s2 ) true
invece
s1 == s3 false
e
s1.equals( s3 ) true
In generale String s1 = "Ciao" è più comodo e sfrutta il pooling 
risparmiando risorse. s3 = new String(Ciao) solo se serve per motivi 
particolari. Al momento non me ne vengono in mente :-)
Ciao
Luca

Per modificare una stringa puoi usare la classe StringBuffer.
Detto cosě, si presta a qualche critica IMHO.
Se per te stringa va letto come String, allora č sbagliato: le String non 
si possono modificare mai.
StringBuffer č un'implemetazione diversa, un contenitore di caratteri con 
il quale si puň costruire una String senza l'overhead di creare molti 
oggetti String per i passi intermedi.
Sulla documentazione č spiegato molto piů chiaramente di quanto possa fare 
io ;-)
-- 
Ciao
	Fabrizio C.

 Direi proprio di no.Guarda l'altro mio post.
Hai ragione. La nuova JLS fa menzione esplicita alle stringhe costanti.


 Quindi per ogni String litteral esiste un unico oggetto String.
No! No!
Leggi attentamente qui sotto:
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#241669
This example illustrates six points:
- Literal strings within the same class (§8) in the same package (§7)
  represent references to the same String object (§4.3.1).
- Literal strings within different classes in the same package represent
  references to the same String object.
- Literal strings within different classes in different packages likewise
  represent references to the same String object.
- Strings computed by constant expressions (§15.28) are computed at compile
  time and then treated as if they were literals.
- Strings computed at run time are newly created and therefore distinct.
- The result of explicitly interning a computed string is the same string
  as any pre-existing literal string with the same contents.
Letti e digeriti i primi tre punti?
Quindi riassumiamo:
 - strings literal uguali (nella stessa classe, o in differenti classi
   o in differenti packages) si riferiscono *sempre* allo stesso oggetto;
 - stringhe generate a run-time sono *sempre* distinte.
-- Dario

 
Piu' correttamente il riassunto sarebbe:
- per le stringhe che possono essere calcolate a compile-time (e quindi,
costanti, non solo i litterals) esiste un'unica istanza di String.
- per quelle che devono essere calcolate a run-time viene creata ogni volta una
nuova istanza.
Guarda infatti cosa succede con il seguente codice:
String hello = "Hello", lo = "lo";
final String lo2 = "lo";
System.out.print((hello == ("Hel"+lo)) + " ");
System.out.println((hello == ("Hel"+lo2)) + " ");
Il risultato e':
false true


 nuova istanza.
Concordo: e' il sesto punto delle specifiche sopra citate:
  - Strings computed at run time are newly created and therefore distinct.
-- Dario

 
Sara' come dici tu, ma per me "likewise" non e' la stessa cosa di
"always". Secondo me, il fatto che ci sia scritto "likewise" significa
che un compilatore potrebbe istanziare due oggetti diversi per lo stesso
literal presente in due classi in due package diversi.
Non e' detto che qualche compilatore effettivamente lo faccia, ma (da
specifica) potrebbe farlo.
In ogni caso anche in "The Java Programming Language" (Arnold, Gosling &
Holmes) la faccenda viene liquidata semplicemente con "any two string
literals with the same contents will refer to the same String object".
Direi che (malgrado la JLS) l'interpretazione da dare e' questa (se non
lo sanno loro :-)).
Lo so, e' un po' brutto...sa da "ipse dixit"...


 No! No
Si! Si! :)
uL

 caso).
No, devono essere uguali da spec. Sicuramente da java 1.2, sinceramente 
non ne sono certo per 1.0 e 1.1. Scommetto di si, ma mi riservo di 
controllare e correggere.
ciao
uL


Mi sono ricordato, anche da 1.1 :) Tanto che c'e' una domanda sul mio 
sito (i test sono del 97 e java 1.2 non c'era) che testa proprio questo 
"comportamento" della jvm
Anche nella certificazione Java Programmer (da 1.1 in poi) c'era questa 
domanda...
ciao
uL

 wrote in
news:3D98BDC3...@flashnet.it
: 

Ho guardato ieri, e in JLS1 la cosa era semplicemente meno chiara, ma 
c'era. In JLS2 hanno aggiunto una frase esplicita, che chiarisce l'ambito 
di applicazione di intern().
La confusione forse puo' nascere dal fatto che la cosa si riferisce a 
stringhe costanti - e non a stringhe computate a runtime. 
