Re: [patch] java.io.File fixes and String.substring() optimization

[Warren Levy <warrenl@cygnus.com>]

On Wed, 28 Jul 1999, Bryce McKinlay wrote:

> Tom Tromey wrote:
> 
> > >>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:
> >
> > Bryce> The former fix also prompted me to check if String.substring()
> > Bryce> would do the right thing if it was called with (0, length) - it
> > Bryce> should probably return itself in this situation (the spec says
> > Bryce> somewhere that strings with equivalent content can and should
> > Bryce> be the same object, right?), so I patched that too.
> >
> > Do you have a reference for this?
> 
> public class Substr
> {
>   public static void main(String args[])
>     {
>       String a = "asdfg";
>       String b = a.substring(0, 5);
>       if (a == b) System.out.println("same");
>     }
> }
> 
> [bryce@reason tests]$ java Substr
> same
> [bryce@reason tests]$
> 
> Remember, the "==" operator tests for object equality, NOT string
> equality.

FWIW I've heard this bit about String equality too (though I can't say if 
my recollection is based on "folklore" passed to me when learning Java or 
if I saw it in Sun doc).  If you look though at the JCL book at 
String.intern(), it seems clear that strings that are equal may *not* be 
the same object!  Otherwise, there would be no need to have the 
intern() method to optimize checking for equality ("==" would suffice).

My guess is that from an implementation standpoint (e.g. using the 
"string pool"), string object equality was an optimization goal for Sun 
but not a hard & fast requirement.

As a side note I remember hearing/reading that a String created with 
substring() relates to the String it came from such that unexpected 
side-effects can result on the other via certain manipulations.  I have 
no idea if this last bit is true in the Sun implementation (I highly 
doubt this is part of any spec), but if the String and the substring(0, 
length) are the same object, I guess it is possible.  I don't think these
kind of side-effects are possible in libgcj, so I'd think that Bryce's 
substring patch is safe and fine as an optimization.
--warrenl