The StringBuilder class has exactly same methods as the old StringBuffer class, but StringBuilder is faster because
it's methods are not synchronized. Both classes give you String like objects that handle some of the String class's
shortcomings (like IMMUTABILITY)
I am just wondering what this paragraph means. I know that String immutability is not a short-coming so whats the
crux of this sentence. May be i am understanding it wrong.
It's not a design flaw of String. But sometimes you want an immutable string, and sometimes you want a mutable one. It depends on how you're using it. So StringBuilder gives you something you can use when you need a mutable one.
Is a hammer poorly designed because you can't screw screws in with it?
Well if i am guessing ir right, the only complain that you can have about immutability is when you are doing a lot of input and output, if you are using String objects, then a lot of them are being created and left in the String constant pool without a reference.I think the same can be sorted out if you use the StringBuilder and StringBuffer.
If debugging is the process of removing bugs, then programming must be the process of putting them in. -- Edsger Dijkstra
Thanks a ton for a wonderful explanation of the aspect. I know it is not a short-coming, i was only curious
why the line in the book wrote it as a short-coming. Just a curiosity. But i understand now why they must have
written it. Thanks a ton.
Thanks for the correction, but i personally think, it depends upon the personal choice what we want to call.
Some people say it as K&B, in that case it should be known as S&B. (Again personal choice comes)
So i personally think, it's waste of time to comment over it. Thanks again for your information though
You are just landing a educational discussion on personal terms. I guess better you should concentrate on
answering some questions from other people in the forum rather then wasting time on such nitty gritty issues.
I already told you, good that you have given this input but it doesn't mean you keep the thread going for no
good reasons. Grow up.
Now lets all take a deep breath and calm down shall we. We try to be friendly to other people at this place. Lets put an end to this discussion and not escalate it...
Java's got a huge API - that's because there's no single solution for every problem. For instance, if you look at the collections-related classes in java.util you will find that each class has its strengths and each has its weaknesses. Maps are better for some problems and Lists are better for others.
Oh, BTW, we prefer K&B
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Boss, i will make sure, i mention K&B from now on, sweet, short and simple. This forums rocks.
It was indeed a pleasure that you yourself addressed what i was confused about. Thanks a ton.
For those interested in the design flaws in the APIs themselves, there are a few. java.util.Stack / Properties are examples. But they are beyond the scope of the SCJP