StringBuilder version of java.util.regex.Matcher.append*

[Jeremy Manson]

There aren't really many design points that occur to me here, so I'd be
interested to hear what the problems are:

- Suppress the IOE.  Make users call a method to get the exception out.
 This seems way too fragile to me (no one is going to remember to do that),
but hey, someone decided it was the right thing to do for Formatter.

- Don't suppress the IOE.  Make new variants of this method that throw IOE.
 In this case, you probably want to keep the StringBuffer/Builder variants
around, so that users don't have to insert unnecessary catches into their
code (I can imagine the agonized screaming now).

The second case seems much stronger to me, and in that case, we want this
patch.

Jeremy


On Wed, Mar 19, 2014 at 11:09 AM, Xueming Shen <xueming.shen at oracle.com>wrote:

> Similar suggestion has been on the to-do list for a while. There were
> discussion back
> then that it might be interesting to add the more general interface
> Appendable...
> The issue was how to deal with the IOE declared by the Appendable methods
> then.
>
> If the appendable is not going to happen, then it is definitely worth
> adding the StringBuilder
> for better performance.
>
> -Sherman
>
>
>
> On 03/19/2014 10:51 AM, Jeremy Manson wrote:
>
>> I'm told that the diff didn't make it.  I've put it in a Google drive
>> folder...
>>
>> https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/
>> edit?usp=sharing
>>
>> Jeremy
>>
>>
>> On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson<jeremymanson at google.com
>> >wrote:
>>
>>  Hi folks,
>>>
>>> We've had this internally for a while, and I keep meaning to bring it up
>>> here.  The Matcher class has a few public methods that take
>>> StringBuffers,
>>> and we've found it useful to add similar versions that take
>>> StringBuilders.
>>>
>>> It has two benefits:
>>>
>>> - Users don't have to convert from one to the other when they want to use
>>> the method in question.  The symmetry is nice.
>>>
>>> - The StringBuilder variants are faster (if lock optimizations don't kick
>>> in, which happens in the interpreter and the client compiler).  For
>>> interpreted / client-compiled code, we saw something like a 25% speedup
>>> on
>>> String.replaceAll(), which calls into this code.
>>>
>>> Any interest?  Diff attached.
>>>
>>> Jeremy
>>>
>>>
>