The current code certainly breaks down in the situation you mention and
does do excessive substring() calls on large values of i...
But if you really want to get efficient, you don't actually need the j
variable in your chop(String, int, String) method... :)
--
Patrick E. Whitesell
[EMAIL PROTECTED]
John McNally wrote:
> The StringUtils.chop method assumes the String to be chopped will only
> contain EOL that are given by the line.separator property. This can be
> wrong in many circumstances. The way I read the current implementation,
> if the String contains \n and the line separator is \r\n, an extra
> character will be chopped. If the String contains \r\n and the line
> separator is \n, the EOL will be considered 2 separate characters. The
> current method is also inefficient for chopping several characters as
> well.
>
> Here is a patch that provides a method for applications that can assume
> the String and system line separators are the same. As well as a method
> that allows the application to specify the EOL.
>
> John McNally
>
> (if the patch is accepted or considered, I will be happy to regenerate
> diff after dlr's changes.)
[snip]
