Why String class immutable

[deepak carter]

Hi all,

Why java creator developed String class immutable and what exactly is the use of immutable class.?

[Seetharaman Venkatasamy]

So that you can share the object between multiple people with out worrying about the content.
for instance: String Constant Pool in java

[Stevens Miller]

This might be useful to you:

http://www.javaranch.com/journal/2003/04/newsletterapr2003.jsp#a3

[chris webster]

More generally, immutable objects have certain advantages e.g. immutable objects are thread-safe. If you and I have references to the same object A in separate threads, we still can't change the contents of A, so we know that we will always get the same contents when we read A in our separate threads. If A was mutable, your thread might change it so my view of A was no longer consistent with yours.

If you make your objects immutable, it also makes it easier to keep track of what their contents are, because they can't be changed after creation anyway.

Immutability is also one of the key features of functional programming - see Neal Ford's "Functional Thinking" series at IBM DeveloperWorks.

[Stevens Miller]

chris webster wrote:More generally, immutable objects have certain advantages e.g. immutable objects are thread-safe. If you and I have references to the same object A in separate threads, we still can't change the contents of A, so we know that we will always get the same contents when we read A in our separate threads. If A was mutable, your thread might change it so my view of A was no longer consistent with yours.

Chris, may I probe that point a bit? I'm doing a lot of multi-threaded coding lately, and can use all the guidance I can get.

Seems to me that, if one benefit of immutability is that two threads can rely on the content of an immutable object not to change, then the code in each thread would never try to change that object's contents. For an immutable object like, say, a String, there is no way for your Java code to change its contents. But is that a "benefit" of the immutability of the object, or a restriction imposed upon the program? Or both? What I'm (probably clumsily) trying to get at is that, if you and I have references to the same object A in separate threads, we can agree not to change the contents of A, whether it is immutable or not. If A is immutable, that agreement is enforced by the object's design. If A is not immutable, the agreement will still yield the same benefit as if A were immutable, just without the design of A enforcing the agreement upon us. Put another way, the same code as is allowed when A is immutable would work just as well, and be just as effective in guaranteeing that neither thread changes A, when A is mutable.

Is that a valid way to look at this aspect of immutability? That it prevents code from changing an object's contents, whereas, for mutable objects, we can only trust each other not to make changes?

[chris webster]

Stevens Miller wrote:Chris, may I probe that point a bit? I'm doing a lot of multi-threaded coding lately, and can use all the guidance I can get.

Well, as I'm probably just reading the same web pages as you are on this stuff, and I've never done any explicitly multi-threaded programming, I don't think it'll help you much!

Stevens Miller wrote:...Is that a valid way to look at this aspect of immutability? That it prevents code from changing an object's contents, whereas, for mutable objects, we can only trust each other not to make changes?

The FP brigade seem to require immutability because it means that every time you call a function with the same inputs you get the same output, with no side effects, which is obviously pretty important.

Even in Java, Joshua Bloch's "Effective Java" (Bloch, Joshua. Effective Java (2nd Edition), pp. 73ff) has a section on why it's a good idea to make your classes immutable if possible, because:

"Immutable classes are easier to design, implement, and use than mutable classes. They are less prone to error and are more secure."

He goes on to illustrate how to achieve this, and explain various reasons why it's a good idea. The common theme is that immutable objects are much easier to manage, use as building blocks, or share, and they do not need to be copied because a given object only ever has one state so you can always use the original instance. The only downside he identifies is that you need a separate object for each distinct value - you can't just change the contents of an existing instance - so there are situations where you could end up creating lots of intermediate instances before you get to the one you want (think concatenation with Strings vs. StringBuilder) which is obviously wasteful of resources (memory). Despite that caveat, he's pretty gung-ho about the benefits of immutable classes:

Classes should be immutable unless there's a very good reason to make them mutable. Immutable classes provide many advantages, and their only disadvantage is the potential for performance problems under certain circumstances.
...
If a class cannot be made immutable, limit its mutability as much as possible. Reducing the number of states in which an object can exist makes it easier to reason about the object and reduces the likelihood of errors. Therefore, make every field final unless there is a compelling reason to make it nonfinal.

Anyway, it sounds pretty convincing to me.

Incidentally, if you're doing multi-threaded stuff, have you looked at Scala's Actors as an alternative?

[Mike Simmons]

Stevens Miller wrote:if you and I have references to the same object A in separate threads, we can agree not to change the contents of A, whether it is immutable or not. If A is immutable, that agreement is enforced by the object's design. If A is not immutable, the agreement will still yield the same benefit as if A were immutable, just without the design of A enforcing the agreement upon us. Put another way, the same code as is allowed when A is immutable would work just as well, and be just as effective in guaranteeing that neither thread changes A, when A is mutable.

No, that's not quite true. There are cases where the JVM handles fields a little differently if they are final than if they are not final - and in a multi-threaded context, if you access a nonfinal field without any synchronization, you can get some very unintuitive results. Like a field may show up as 0 or null even though another thread initialized it to some other value. The people who set up the rules figure that if you didn't make it final, you plan to change it, and therefore you need synchronization to view it safely - therefore they don't put in any special protection to prevent these unintuitive results. But if you make it final, they put in protection so you won't see those unintuitive results, even when not using synchronization. So basically, if you don't make a field final, you need extra measures to make a field thread-safe, if you're using multiple threads.

[Seetharaman Venkatasamy]

I think Stevens Miller didnt say about changing the mutable object(immutable- agreement between A and B) between threads. A and B thread use the object only for read(even though that is mutable).

[Winston Gutkowski]

Stevens Miller wrote:Seems to me that, if one benefit of immutability is that two threads can rely on the content of an immutable object not to change, then the code in each thread would never try to change that object's contents. For an immutable object like, say, a String, there is no way for your Java code to change its contents. But is that a "benefit" of the immutability of the object, or a restriction imposed upon the program? Or both? What I'm (probably clumsily) trying to get at is that, if you and I have references to the same object A in separate threads, we can agree not to change the contents of A, whether it is immutable or not...
Is that a valid way to look at this aspect of immutability? That it prevents code from changing an object's contents, whereas, for mutable objects, we can only trust each other not to make changes?

Pretty much, but there's a fair bit more to synchronization than just "agreeing not to change".
Most large projects involve many programmers of differing skills, so it's not just about managing your objects; it's also making sure that someone else (a 'client', but possibly also a colleague) can't do anything that you didn't intend them to.

And this is where all the business about information hiding, loose coupling and cohesion really count. You know your classes, but how do you prevent someone else from using them for something that they were never intended? - either deliberately or by accident. And for that, immutability is wonderful. I'm an old C programmer, so the 'functional' side of it I totally understand (for starters, I hate methods that return void; although I've been dragged screaming to the realization that sometimes they're necessary), but there's quite a lot more to it than just that.

Chris quoted Josh Bloch, so I'll give you one of his examples - a million bit BigInteger. You want a copy of that value? No probs: I just create a new BigInteger that references the same value. No worries, because you can't change it. Same thing with multi-threading: no synchronization worries, because there's nothing to synchronize.

Winston

[Stevens Miller]

Mike Simmons wrote:

Stevens Miller wrote:Put another way, the same code as is allowed when A is immutable would work just as well, and be just as effective in guaranteeing that neither thread changes A, when A is mutable.

No, that's not quite true. There are cases where the JVM handles fields a little differently if they are final than if they are not final - and in a multi-threaded context, if you access a nonfinal field without any synchronization, you can get some very unintuitive results. Like a field may show up as 0 or null even though another thread initialized it to some other value.

Mike, I think if the other thread can initialize a field, that is going to call for synchronization whether the other field is final or not. That's because the thread that does not initialize the field has no way, without synchronization, of knowing if the other thread has initiatialized that field at any given moment or not. Even if making it final guarantees both threads see the same value after initialization, it doesn't help the non-initializing thread's need to be able to determine if the field has been initialized or not. OTOH, if the object has been initialized before another thread is created, I believe synchronization is implicit and that any caching or other issues that might confuse the second thread are avoided (since it must load the field at least once upon the first reference, and, by that time, it has already been initialized).

Or so I am guessing.

[Stevens Miller]

Winston GutkowskiMost large projects involve many programmers of differing skills, so it's not just about managing your objects; it's also making sure that someone else (a 'client', but possibly also a colleague) [i wrote:can't[/i] do anything that you didn't intend them to.

Oh, yeah, I get that. Everything changes when Programmer 2 can't be relied up to adhere to any contracts proposed by Programmer 1. And, indeed, I would accept that Programmer 2 can even be Programmer 1.

[Stevens Miller]

chris webster wrote:The FP brigade seem to require immutability because it means that every time you call a function with the same inputs you get the same output, with no side effects, which is obviously pretty important.

Even in Java, Joshua Bloch's "Effective Java" (Bloch, Joshua. Effective Java (2nd Edition), pp. 73ff) has a section on why it's a good idea to make your classes immutable if possible...

I'll try to get a copy of that. I keep seeing references to what a good guide it is.

As for FP, well... I was forced to write some Lisp programs to get my master's degree in computer science. To this day, I have never really understood how they worked. I would probably have tried harder to make sense of them, but something about the mildly manic demeanor Lisp programmers seem to display when you ask them, "What's so good about functional programming?" always tended to put me off.

[chris webster]

Stevens Miller wrote:As for FP, well... "What's so good about functional programming?" ...

Still time to sign up for Martin Odersky's FP with Scala course...

[Mike Simmons]

Stevens Miller wrote:Mike, I think if the other thread can initialize a field, that is going to call for synchronization whether the other field is final or not. That's because the thread that does not initialize the field has no way, without synchronization, of knowing if the other thread has initiatialized that field at any given moment or not. Even if making it final guarantees both threads see the same value after initialization, it doesn't help the non-initializing thread's need to be able to determine if the field has been initialized or not. OTOH, if the object has been initialized before another thread is created, I believe synchronization is implicit and that any caching or other issues that might confuse the second thread are avoided (since it must load the field at least once upon the first reference, and, by that time, it has already been initialized).

If a field is final, then the only way it can be initialized is at construction time. Designing classes this way forces clients to initialize the object up front, and after that, they can't possibly be not initialized. And clients in other threads never have to wonder if the field was initialized or not - it was, because it had to be. And no one needs any synchronization to check this. It's guaranteed, as long as the field is final.

For a non-final field, all that goes away. People should use synchronization to access any mutable field in a multithreaded environment, but often they don't. Maybe they don't realize they're dealing with multiple threads. Or maybe they're under the illusion that just because no one is changing the fields after initialization (which may have even been done in the constructor), they don't need to worry about mutability. But if the field is not final, they're wrong.

[Stevens Miller]

Mike Simmons wrote: Or maybe they're under the illusion that just because no one is changing the fields after initialization (which may have even been done in the constructor), they don't need to worry about mutability. But if the field is not final, they're wrong.

I think I kept up with all the rest, but this last part I'm not grokking yet. If a field is initialized before the second, accessing thread is created, I believe synchronization is implicit. If the field is initialized after the second (again, accessing) thread is created, it seems that synchronization is necessary, whether it is final or not, because there is no way for the second thread to know if the field has been initialized without synchronization.

Sounds like you know your stuff, Mike, so I'm probably getting something wrong here. If you see what it is, please straighten me out.

Meanwhile... this whole mutable/immutable thing kind of light a fire in me this weekend, so I did some homework and... wow! That's some powerful stuff! Took me a couple of reads to get a handle on the Liskov substitution principle and what "covariance" and "contravariance" mean. But, once that sank in, the utility and virtue of some aspects of immutability really came through.

Chalk up another lesson learned for me from this excellent group.

(For those who might be wondering, "He didn't know about the Liskov substitution principle? Just what was he studying when he went to graduate school?", I will say in my own defense that Liskov and Wing wrote their paper describing the LSP in 1994. I got my degree in 1988. Yes, we had computers in 1988. )

[Bear Bibeault]

Stevens Miller wrote: I got my degree in 1988. Yes, we had computers in 1988. )

Whippersnapper!

[Stevens Miller]

Bear Bibeault wrote:

Stevens Miller wrote: I got my degree in 1988. Yes, we had computers in 1988. )

Whippersnapper!

Heh. Gotcha beat, old man. From your bio:

Bear has been turning coffee into quality software since 1976 when he starting programming in BASIC on a Control Data Cyber.

I started programming in BASIC on an HP 2000.

In 1974. (On one of these, no less.)

(OTOH, I can't touch your bibliography. Very impressive.)

[Bear Bibeault]

I still miss the clatter those teletypes made. (Not.)

[Mike Simmons]

Stevens Miller wrote:
I think I kept up with all the rest, but this last part I'm not grokking yet. If a field is initialized before the second, accessing thread is created, I believe synchronization is implicit.

Well, yeah, that would sure make intuitive sense. But it isn't actually the case. The problem is that Java allows for all sorts of compiler optimizations, potentially reordering operations and caching values as long as the reordering and caching would have no effect on behavior as seen from a single-threaded model. Unfortunately when the same optimized code is run by multiple threads, very unintuitive results can occur. They put in some safeguards, specifically around synchronized code and code that accesses final fields, because programmers need some mechanism to require more consistent behavior when communicating between different threads. But synchronization has some overhead, and they don't throw it in for free anytime we might expect synchronization to be there.

You may want to check out JLS 17.5, Final Field Semantics. It's a dreary read, but in particular check out Example 17.5.1. They observe that f.x is guaranteed to be 3, but f.y could be 0 (default value) or 4 (initialized value). The only significant difference between f.x and f.y (besides different initialization values) is that x is final, and y is not. That makes y's behavior unpredictable. Because the JLS puts in specific guarantees for final fields, that you will not obe able to observe them in their uninitialized state from outside the constructor. And such guarantees simply do not exist for non-final fields. So you're at the mercy of unspecified compiler optimizations.

Stevens Miller wrote:If the field is initialized after the second (again, accessing) thread is created, it seems that synchronization is necessary, whether it is final or not, because there is no way for the second thread to know if the field has been initialized without synchronization.

If the field is final, then the second thread will not be allowed to access anything about the object until after the constructor completes. Even if the thread started before the field was initialized. But no such guarantee exists for a non-final field.

[Stevens Miller]

Mike Simmons wrote:

Stevens Miller wrote:
I think I kept up with all the rest, but this last part I'm not grokking yet. If a field is initialized before the second, accessing thread is created, I believe synchronization is implicit.

Well, yeah, that would sure make intuitive sense. But it isn't actually the case. The problem is that Java allows for all sorts of compiler optimizations, potentially reordering operations and caching values as long as the reordering and caching would have no effect on behavior as seen from a single-threaded model.

Ah, I think I get it. I (apparently incorrectly) had assumed a memory fence would be erected at the point where a new thread was created. You are saying, I think, that such a fence exists for finals, but not in general. How about for volatiles? (I know that any mention of "volatile" provokes something akin to red-faced rage in the C++ community, but my reading says that word means something different in a Java context.)

Mike Simmons wrote:

Stevens Miller wrote:If the field is initialized after the second (again, accessing) thread is created, it seems that synchronization is necessary, whether it is final or not, because there is no way for the second thread to know if the field has been initialized without synchronization.

If the field is final, then the second thread will not be allowed to access anything about the object until after the constructor completes. Even if the thread started before the field was initialized. But no such guarantee exists for a non-final field.

The synchronization I am thinking of is at the level of the object that contains the field. The second thread is going to need some way of knowing if the object's constructor has been called at all, regardless of whether or not it even does any internal initialization, isn't it?

I'll have a look at that material you found. This is all quite interesting, in its own dreary CS sorta way.

[Stevens Miller]

Bear Bibeault wrote:I still miss the clatter those teletypes made. (Not.)

I get you. The wonderful thing about the ASR 33 and its kin was that, when you pressed a single key, the result sounded something like a machine gun going off. Even as the two-finger typist I was in those days, when I used one, it seemed as though I was entering code at a ferocious rate.

However, the fact that the 110-baud ASR 33 was, compared to a modern keyboard and screen, what a coal-fired steam engine would be, compared to an A380, only tells you what there really is to miss. I mean, sure, the latter in each case is more sleek, has greater capacity, and is much more reliable. But, which one gets your heart to race, the airbus, or the iron horse?

[Stevens Miller]

Mike, I really have to thank you for that pointer to Chapter 17 of the JLS. You're right that it is a bit dry and tedious in some spots. (I'm never sure if the use of, for example, set notation, in such things as language specs is truly useful, as opposed to a mildly poignant, yet also mildly annoying, bit of evidence that Computer Science is a little nervous about whether or not it is closer in nature to Physical Science than to, say, Hotel Science, but we'll leave that for another day.)

Fortunately for me, I have recently had to learn about reordering and its potential effects on multi-threaded access to shared memory, so the examples seemed familiar. The original question, about the virtues of String immutability, gets its best answer from an understanding of the issues Chapter 17 addresses, but there's a lot more in that chapter than that.

Here's some of what I think I gleaned:

17.4.5 wrote: A write to a volatile field (8.3.1.4) happens-before every subsequent read of that field.

This appears to answer my question to you about whether or not volatile fields are safe against reordering between threads.

17.5 wrote:A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.
(emphasis mine)

This appears to confirm my notion that, even though final fields are synchronized between threads, some mechanism must be employed by the accessing thread to prevent access until after initialization is complete. The example you pointed me to actually does this:

class FinalFieldExample { 
    final int x;
    int y; 
    static FinalFieldExample f;

    public FinalFieldExample() {
        x = 3; 
        y = 4; 
    } 

    static void writer() {
        f = new FinalFieldExample();
    } 

    static void reader() {
        if (f != null) { // THIS TEST EFFECTIVELY SYNCHRONIZES ONE THREAD'S CALL TO reader() WITH ANOTHER THREAD'S CALL TO writer()
            int i = f.x;  // guaranteed to see 3  
            int j = f.y;  // could see 0
        } 
    } 
}

You can see what I have in mind from my COMMENT IN CAPS. Testing for f != null is, imho, kind of a rinky-dink way to synchronize access, but I can imagine code that would either proceed to access f's fields, or proceed to something else, but would not want to block while waiting for f to be constructed, so it's clearly not invalid.


Now, elsewhere, Chapter 17 says this:

17.4.4 wrote:An action that starts a thread synchronizes-with the first action in the thread it starts.

Does this mean one could protect against reordering of assignments to non-final (and non-volatile) fields when accessing them from a second thread (that is, a thread that did not assign them their value), by conditioning creation of the second thread on the field having been assigned a value in the first thread? Something like this:

int x;

x = y;

if (x != 0)
    startSecondThread();

Here, I am hoping the "action that starts a thread" is the test "x != 0" and its reliance upon x having a value to be compared against 0. The assignment "x = y" might be reordered, but is it safe to assume it has been executed no later than the access to x in the "if" statement, and, therefore, that assignment synchronizes-with the first action in any thread created by startSecondThread()? Or am I overlooking yet another reordering-like optimization the compiler might contribute, that defeats my expectations here?

[UPDATE: This appear to be my 100'th post on coderanch.com. This is far and away the best Java forum I have found.]

[Mike Simmons]

I think the answer to all those questions is "yes" - except the last "am I overlooking something", which is "no". But that's on a quick read-through, and to be honest I don't remember all the details of how these rules work; it takes some time and effort to reabsorb them. I'll try to give it a longer look later. Glad you're finding the link useful.

[Stevens Miller]

Mike Simmons wrote:I think the answer to all those questions is "yes" - except the last "am I overlooking something", which is "no". But that's on a quick read-through, and to be honest I don't remember all the details of how these rules work; it takes some time and effort to reabsorb them. I'll try to give it a longer look later. Glad you're finding the link useful.

I really am, and thanks again.

It seems as though, every five to ten years, I get deeply involved in programming again. That schedule lets just enough change that I have to do the equivalent of going back to school each time. It's a mixed blessing, because it always reminds me of why I fell in love with coding in the first place (you get a lot of "that's so cool!" moments), and of what a harsh mistress code can be ("what do you mean I can't port 10,000 lines of C that manage arrays of unsigned bytes into Java???").

Anyway, thanks to your help and this thread, I believe I knowingly used "final" for the first time today in a class I created.

Keep the good stuff comin', boys. I may be old, but I ain't dead yet.

[Winston Gutkowski]

Stevens Miller wrote:Keep the good stuff comin', boys. I may be old, but I ain't dead yet.

Like Bear said: whippersnapper.

Me: First programming at school - Basic on a PDP-8E in 1971. First job (1976): COBOL on an ICL-1906S, running GEORGE III (brilliant OS). 6 months earlier and I'd have been doing Autocoder on a 1401. Anyone else here still remember how to make Christmas stars out of paper tape?

Just a quickie point to add to Mike's great advice: That re-ordering business is possibly the most important thing to know about with the memory model. It applies to - or rather, is restricted by - final, AND volatile fields (and, of course, synchronization) by imposing 'happens before' rules. Personally, I have to re-read them pretty much every time I'm doing something complex, but I blame it on the Alzheimer's.

Winston

[Stevens Miller]

Winston Gutkowski wrote:

Stevens Miller wrote:Keep the good stuff comin', boys. I may be old, but I ain't dead yet.

Like Bear said: whippersnapper.

Me: First programming at school - Basic on a PDP-8E in 1971. First job (1976): COBOL on an ICL-1906S, running GEORGE III (brilliant OS). 6 months earlier and I'd have been doing Autocoder on a 1401. Anyone else here still remember how to make Christmas stars out of paper tape?

Hollerith cards. I have made them out of Hollerith cards. (The real fun with paper tape was saving the dots the ASR 33 left in that bucket underneath the punch. Because of the little bit of lubricating oil on that tape, they stuck really well and were very hard to comb out when you threw them in the girls' hair in the hallway.)

But... a PDP-8E, huh? Impressive. I bow to your superior experience, venerable sir.

Just a quickie point to add to Mike's great advice: That re-ordering business is possibly the most important thing to know about with the memory model. It applies to - or rather, is restricted by - final, AND volatile fields (and, of course, synchronization) by imposing 'happens before' rules. Personally, I have to re-read them pretty much every time I'm doing something complex, but I blame it on the Alzheimer's.

Heh. At least Java is pretty clearly spec'ed about those things. Try reading the MSDN on how you can be sure (or if you even can be sure) that you have achieved shared memory coherence between threads under Windows. It says you can trust the synching functions to erect fences for you, which is great for handling reordering, but it never quite seems to say you can be sure your shared data isn't being cached in another thread (which means you can't be sure it's got the same value in each thread). There's some tantalizing stuff about globals, and so on, that I think makes the promise you need, but... well, I hope my code works, that's all I can say.

[Junilu Lacar]

Stevens Miller wrote:In 1974. (On one of these, no less.)

I only go as far back as the old IBM S/36 keyboards. And talk about clatter, those things were obnoxious, especially if you made an error.

[Campbell Ritchie]

Stevens Miller wrote: . . . (On one of these, no less.) . . .

Did you have the paper tape with holes in, and the little hand‑operated reels to wind it up neatly? Did you use ctrl‑shift‑P‑repeat to get the neat blank leaders and tails for the paper tape? I can remember trying to model extraction columns in BASIC back in 1971. Time‑sharing on a Honeywell system.

[Stevens Miller]

Campbell Ritchie wrote:

Stevens Miller wrote: . . . (On one of these, no less.) . . .

Did you have the paper tape with holes in, and the little hand‑operated reels to wind it up neatly? Did you use ctrl‑shift‑P‑repeat to get the neat blank leaders and tails for the paper tape? I can remember trying to model extraction columns in BASIC back in 1971. Time‑sharing on a Honeywell system.

We used to wind our paper tape in a figure-8 around our thumb and index finger(s). By laying it flat at the cross-over, you could feed it back into the reader from the start while holding the "eight" in your palm, with no need to unreel it or worry about loops being sucked into the reader (and scrunched into mangled strips you would have to painstakingly repair with tweezers and Scotch tape; ah, those were the days, eh?).

[Atul Singhal]

I found below link quite useful to understand why strings are immutable and how they behave.

http://www.javaranch.com/journal/200409/Journal200409.jsp

[Campbell Ritchie]

That’s a good link.

[Prateek Kumar Singh]

After some r&d i find some interesting reasons for why String class is immutable .

there are following point which makes String class immutable -
1. automatically thread-safe and have no synchronization issues
2. do not need a copy constructor
3. do not need an implementation of clone
4. allow hashCode to use lazy initialization, and to cache its return value
5. do not need to be copied defensively when used as a field
6. make good Map keys and Set elements (these objects must not change state while in the collection)
7. have their class invariant established once upon construction, and it never needs to be checked again


Cheers
Prateek Singh

[Campbell Ritchie]

prateek garg wrote:After some r&d . . .

Well done

And thank you for the summary of the reasons.