what is the need for copy constructor in String class?

[Piper707]

Hi,

I've always read that strings should be created like this:

String test = "hello" rather than String test = new String ("test").

I understand why this is recommended and the concept of string pools,
but now I can't seem to understand why anybody would want to use the
constructor? why is it provided in the first place?

Thanks
Rohit

 

[Joshua Cranmer]

Hi,

I've always read that strings should be created like this:

String test = "hello" rather than String test = new String ("test").

I understand why this is recommended and the concept of string pools,
but now I can't seem to understand why anybody would want to use the
constructor? why is it provided in the first place?

The biggest reason for the latter invocation that I can imagine off the
top of my head is that test (in the first case) cannot be garbage
collected, but it can in the second case.

 

[Donkey Hottie]

The biggest reason for the latter invocation that I can imagine off the
top of my head is that test (in the first case) cannot be garbage
collected, but it can in the second case.

I disagree. "hello" is NOT an Object of type String, it is a character
sequence. I think the compiler compiles it to a new String("hello"), when
the can be garbage collected.

The "hello" character sequence of always will stay in the byte code file,
but not the object.

 

[Joshua Cranmer]

I disagree. "hello" is NOT an Object of type String, it is a character
sequence. I think the compiler compiles it to a new String("hello"), when
the can be garbage collected.

Literal strings are equivalent to their interned representations (see
<http://java.sun.com/javase/6/docs/api/java/lang/String.html#intern()>
if you don't believe me). So "hello" will be treated by the JVM as an
interned string--via the ldc bytecode instruction. This will load the
constant string literal of that value, i.e. the interned value of that
string. Interned strings are not collectible (though they may be now, if
the enclosing class constant is collected), whereas the copy is collectible.

But no, "hello" is not transformed to new String("hello") by the
compiler. In fact, the JLS prohibits this, since new String("hello") !=
new String("hello") (by virtue of how strings and != work), where JLS
requires that "hello" == "hello" (JLS §3.10.5).

 

[Piper707]

Thank you to everyone who responded, specially Eric - that was a clear
explanation.

With regards to Joshua's comment, if literals do not get garbage
collected, would that not pose a problem from a memory point of view
if my program has a lot of strings? Does the size of the string
constant pool vary dynamically or is it fixed?

 

[Mike Schilling]

The biggest reason for the latter invocation that I can imagine off
the top of my head is that test (in the first case) cannot be garbage
collected, but it can in the second case.

But the constant string (the same as test is the first case, but different
in the second) will be equally collectable either way.

There's this, which I very much doubt is the reaon for the Strng(String)
constructor:

private String mutex = new String("protect internals of foo");
synchronized(mutex)
{
...
}

Giving a mutex a meaningful name can help deadlock analysis. using new
String() prevents two mutexes meant to be distinct from accidentally being
the same.

 

[Steve Wampler]

Thank you to everyone who responded, specially Eric - that was a clear
explanation.

With regards to Joshua's comment, if literals do not get garbage
collected, would that not pose a problem from a memory point of view
if my program has a lot of strings? Does the size of the string
constant pool vary dynamically or is it fixed?

You can't create new string literals/constants at runtime, so this
isn't a problem.

 

[Lew]

You can create new String constants at run time by loading
classes that contain String constants not seen before.

If you load enough classes with enough distinct String
constants, you could in theory chew up a lot of memory. But
it's not likely to get very bad, not unless you load a lot
of mechanically-generated classes or something. Look at the
actual amounts of memory some of your programs use, and get a
feel for how much -- and how little! -- is String data.

Also, fat use of String#intern() can donate the load of Strings in the
intern broccoli.

--
Lew


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"The thesis that the danger of genocide was hanging over us
in June 1967 and that Israel was fighting for its physical
existence is only bluff, which was born and developed after
the war."

--- Israeli General Matityahu Peled,
Ha'aretz, 19 March 1972.

 

[Mike Schilling]

Also, explicit use of String#intern() can increase the load of
Strings in the intern pool.

Though stringa in the intern pool can be collected if they're not
otherwise referenced.