Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.straub-nv.de!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Substring changes (JDK 1.7) Date: Thu, 10 Jan 2013 22:58:24 +0100 Lines: 19 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net YpjQvZvsVDbUpCDoI7tKgwWFP9DmwoR+Jnz7vuE3eY++8dQ+37NJwzXRr7nKDYs/s= Cancel-Lock: sha1:M+U/yVZscQ0Cfh/FoCMrVHhmkZE= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:21312 On 10.01.2013 21:22, Roedy Green wrote: > If this change happens, you would no longer consider using new String( > String) to unencumber a substring. > > You no longer have to worry a about a tiny substring holding a meg+ > sized base string around in memory. Instead you have to worry about tons of substrings drawn from the same input String to occupy a lot more memory and slowing down GC. Trade offs, trade offs... Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/