Difference between String variable and String Class definition

[Jussi Piitulainen]

Tom Fredriksen writes, referring to new String("java"):

What we want is an string object with the given value, the second
seems to do more work than necessary, for the string case, so why
not optimise it away?

Why bother? One should write just the simpler "java": The writer of
the code has less to do. The reader of the code has less to do. The
compiler writer has less to do. The program itself has less to do.
Just about everybody is happier.

Let the compiler writer spend their time on things that are generally
useful in the programs that people actually write.

And stop writing new String("java"), please. Where do people pick this
up anyway? Do they just like the tedium? Could they be convinced to
write "java".intern().intern().intern() instead? (It's even longer.)

 

[Eric Sosman]

Tom Fredriksen wrote On 03/30/06 12:10,:

[...]

To answer your question, I think: programatically yes, but in essence
its the same thing: both are requesting a string object with the given
value.

So then the question: why not optimise the difference away? since the
difference is only in how the result is created, does it matter that
there is a difference?

Sure. The "optimization" would change the output of:

String a = "Java";
String b = new String(a);
System.out.println(a == b);

An "optimization" that changes the program's output (in
other than time-related ways) is more commonly called a
"compiler bug."

Here's another (rather contrived) program whose
behavior would change:

class Bogus implements Runnable {
public static void main(String[] unused) {
String a = "Java";
String b = new String(a);
new Thread(new Bogus(a)).start();
new Thread(new Bogus(b)).start();
}

private final String key;
Bogus(String key) {
this.key = key;
}

public void run() {
for (; {
synchronized(key) {
do_something();
}
}
}
}

As Java actually behaves, the two threads synchronize
on different String objects and run independently. With
your "optimization" they would synchronize on the same
String object and thus contend with each other.

 

[Tom Fredriksen]

The fundamental promise of `new' is that it will
create a brand-new object, distinct from all existing
objects. The `new' operator can never "recycle" an
old object, not even if the old object's state ("value")
is the same as the one being created.

Ok, I get it now (sorry chris, for the last post). The simpler one only
returns a reference to the object, which is shared. While the one with
new creates an entirely new string object with no sharing.

What confused me was the mentioning of interning a string. That lead to
my perception that the simpler version was different objects but where
the char array was what was shared.

For an immutable class like String this guarantee
of instance uniqueness is less useful. Once the object
is created its contents will remain forever unchanged,
so there's not much point in having multiple copies of
the same unchangeable object lying around.

This is what I was thinking.

However, the
notion of "immutable" is not quite as cut-and-dried as
the simple word makes it sound (there was a recent thread
on this very topic), and the Java language doesn't have
a means to express all the shadings and gradations of
"immutability." In the interests of simplicity, perhaps,
Java has just one `new' operator rather than a host of
slightly different `newish' operators -- and since `new'
must allow mutable objects to work properly, `new' must
always, always, always generate a brand-new object.

Maybe an object could have a qualifier stating that the object is
immutable, e.g. const. That way you don't need to use different new
keywords for different shades of immutability.

Anyway, thanks for clearing this up for me.

/tom