String objects

[Michael Finney]

I searched for this here and did not see the answer. I thought I knew the answer, but today I cannot remember.
Are Strings designed to be thread-safe?
If so, what is the proof? In other words, where in the Java Language Specification or API does it say this? (Viewing the implementation would not be good enough since coding by the API is important to us.)
This all started from a discussion about "".equals(whatever) and whether it was contractually guaranteed to be thread-safe.
Thanks.
[ February 18, 2003: Message edited by: Michael Finney ]

[Anshul Chhabra]

Strings are immutable objects.
Maybe I did not understand the question here, but, why are you worried about thread safety of Strings, if you cannot even modify a String.
At most you can reassign a String reference to a new String Object (or another String Object).
In which case the reference to a String is as safe as you choose to make it.
If I missed something vital please clarify.

[Peter den Haan]

Indeed -- immutability means you've got no threading issues to worry about. Also, the very fact that String literals are being shared implies that they have to be threadsafe.
- Peter
[ February 19, 2003: Message edited by: Peter den Haan ]

[Michael Finney]

That's what I thought too. However, someone said "show me the spec which supports this"

[Jim Yingst]

What, the Word of Peter den Haan isn't good enough for them? It should be. You can add my name too if it helps any. I don't think you'll find anything like this in the JLS; though I could be mistaken. Thread safety of immutable objects is more of a derived property, not a specified one. However you could point the doubter to a copy of Joshua Bloch's Effetive Java. "Item 13: Favor Immutability" contains discussion of this point. "Immutable objects are inherently thread-safe; they require no synchronization." If you can't trust Josh Bloch, who can you trust? Point out the strong endorsements of the book from James Gosling, Gilad Bracha, and Guy Steele on the back cover and forward. If that still doesn't work, bet your colleague a large sum of money that he won't be able to construct an example where an immutable object is unsafe in threads, and tell him to put up or shut up.
Note that you do have to be careful how you define this. The immutable object itself will be thread-safe, but a reference to the object may still require some synchronization. E.g.

public class Foo
{
  private String name;
  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
}

If you have multiple thread accessing a Foo object and changing its name, and you try to evaluate something like

    System.out.println(foo.getName() == foo.getName());

you may find that sometimes it evaluates to false, in defiance of apparent logic. The String object may be immutable, but the reference variable "name" isn't - other threads can change it even while you're in the midst of evaluating an expression. Unless you synchronize the get/set methods, and also use a synchronized block to ensure there's no interruption between the two invocations of getName(). So beware the temptation to think that anything dealing with an immutable object requires no synchronization - there are limits. Hope that helps.
[ February 20, 2003: Message edited by: Jim Yingst ]

[Peter den Haan]

Originally posted by Michael Finney:
That's what I thought too. However, someone said "show me the spec which supports this"

Give them an elementary textbook on concurrent programming. That's the spec that should tell them that immutable objects are safe.
- Peter

[Michael Finney]

Sounds great. Thank you all.

[Mr. C Lamont Gilbert]

Still not sure eh Finney
I told you in the Sun forum as "dnoyeB."
I think their is no mention of thread safety because it is implied by the objects immutability.
For others here, in the Sun forums some people started to bring up other issues such as object creation as a reason to say its not thread safe (since object creation is not a thread safe process). Appearantly their are some papers that state this fact. I would call it sensationalism. And I hope you feel reassured Mr. Finney that Strings and immutable objects in general, are all thread safe. Integer, Boolean, Long, Double, to name a few.

[Mr. C Lamont Gilbert]

I wonder though. Since a 'long' is not thread safe, what makes a reference?

[Jim Yingst]

Well, the VM Spec makes specific exceptions for long and double - operations with those variables don't have to be atomic, period, unless the keyword "volatile" is used. It turns out that even if volatile is used, many VMs violate the spec and treat operations with long and double as non-atomic. But as far as I've heard, this only refers to the case of long or double + atomic. The VM Spec offers a number of specific guarantees regarding other variable types (including reference variables) which seem to effectively ensure that references to immutable objects are thread-safe. I don't recall hearing of any VM Spec violations in this area - if there are any, it would be important to know. The rules given by the VM Spec are rather difficult to interpret, IMO, but the consensus from well-informed individuals like Josh Bloch is that the spec makes reference variables thread-safe (provided the objects referenced are themselves thread-safe).