Kasper G. Christensen wrote:
> Spørgerens problem er
> altså at ved brug af substring bliver den resulterende streng ikke
> automatisk intern'ed?
Nej, spørgerens problem er den udbredte begynderfejl med at tro at
sammenligninger på objekter sammenligner deres indhold. Automatisk
intern'ing ville ikke være ikke så smart som det ved første tanke lyder.
> Hvordan kan det egentlig være? Ryger ideen med
> automatisk intern'ing så ikke lidt?
Nej, ideen er at spare plads/tid, ikke at sløre nævnte misforståelse.
> På sin vis er en String vel altid en
> konstant (jeg tænker på at String er imutable)?
Ja, og derfor kan Java tillade sig ikke at lade substring lave en
kopi, men referere ind i den char[] som kilde String'en indeholder.
Det sparer plads og er (i modsætning til String.intern) særdeles
hurtigt. På den anden side kan det give bagslag hvis der plukkes små
bidder ud af store mængder data - så kan heap forbruget blive voldsomt.
Her er intern en mulig teknik til at give garbage collectoren noget
at spise.
> Mit eksempel er vel forøvrigt korrekt for andre (almindelige) klasser.
Dit eksempel er korrekt for alle klasser (også String), men ikke for
alle måder at oprette objekter på. F.eks. baserer et pattern som
Flywight sig på genbruge små value objekter i stedet for hver gang at
oprette et nyt som måske har samme indhold som eksisterende.
I øvrigt er følgende normalt false:
new String("a") == new String("a")
fordi String constructor bevidst laver en kopi - ellers ville der ikke
være noget point ved at oprette et String objekt på den måde.
Jeg vil dog fraråde at lave programmering som baserer sig på hvornår
forskellige String objekt referencer bliver ens pga intern og genbrug
ifm substring m.v. - det giver for stor risiko for fejl. Svjh reducerer
brug af forskellige classloader's sikkerheden for at String.intern
giver mulighed for indholdssammenligning med ==.
Med andre ord er det sundt at lade som om dit eksempel generelt er
korrekt!
/Johnnie