From: Curt Sampson Date: 2005-01-28T08:38:04+09:00 Subject: Re: Software Reliability and method i/o On Thu, 27 Jan 2005, Austin Ziegler wrote: > I'd have to completely disagree with you here. I think that Java's > choice to make Strings immutable has made the language much more > unpleasant to deal with.... "Much more" unpleasant? I'd like to see some specifics on this. > ...and results in a number of inefficiencies when one -- inevitably -- > must modify the contents of a string object. ... and the overhead of > using StringBuffer all the time is undesirable (especially since you > have to construct a StringBuffer every time you need to deal with this > since everyone returns String objects). Do you have some examples of these efficiencies, with stats to back them up? I've profiled a fair amount of Java, and I've just not seen these "inefficiences" after JDK 1.1. Regardless, if you look at techniques such as ropes (sorry, I don't know of an on-line version of the paper) you'll see that making strings immutable is no barrier to making the implementation of string manipulation extremely efficient. So efficiency is no argument either way. > Matz got it right when he made Strings mutable. James and Guido > got it wrong. Aliasing problems take up programmer time, not computer time, and thus are going to be, in the general case, far more costly than having to explicitly specify a mutable string when you want it. cjs -- Curt Sampson +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA