> String abc = "Abc";
> String def = "A" + "b" + "c";
> String rst = create( "A" ) + create( "b" ) + create( "c" );
> String xyz = new StringBuffer().append( 'A' ).append( 'b' ).append(
> 'c' ).toString();
>
> boolean r1 = abc == def;
> boolean r2 = abc == rst;
> boolean r3 = abc == xyz;
>
> private String create( String in )
> {
> return new String( in );
> }
>
>
> Can you tell me which one of those r1-r4 that are true?? (I can't, and
> I suspect it is compiler/jre dependent, but I think the spec requires
> only abc==def to be true, and the others are (jit-)compiler smartness
> only).
The answer depends on which ones are interned, which like you say is
guaranteed to be at least abc and def. I strongly suspect the others will
*not* get interned and will reference difference objects, but perhaps that
is JVM-dependent.
We only employ this "shortcut" when deciding whether or not to run certain
setters in components. Running the setter isn't harmful if two
logically-equal strings appear to be different because of a reference
equality check -- it's just unnecessary overhead. So basically, it's a
judgement call as to which overhead we want to incur: the string comparison
or the body of the setter. The thought was that the vast majority of the
time a caller calls that setter, they'll be setting a distinct value, so
chances are we'll run the body of the setter anyway, so we save the string
comparison. That being said, I do think it'd be incorrect assume that
that's true 100% of the time and to not have any check - otherwise, the
event becomes semantically incorrect.
-T
