Guess we dropped the ball on this.
I just created a new webrev to optimize Matcher.replaceAll,
by using StringBuilder instead of StringBuffer.
This version of the patch does not add any public APIs,
which has the advantage that this patch can be included in jdk6 as well.
A follow-on patch can add
Jeremy is out for a few days - let's pick this up next week.
In the meantime, we probably don't want
public Appendable appendTail(Appendable a) {
but instead
public T appendTail(T a) {
It would be nice to be able to simply change the signature of the
existing method
that takes a StringBuffer,
On Thu, Aug 13, 2009 at 01:03, Rémi Forax wrote:
> Le 13/08/2009 03:30, Martin Buchholz a écrit :
>>
>> Hi regex/String team,
>>
>> We would like to contribute a performance improvement for Matcher.
>>
>
> Just a minor comment, there is not @since 1.7
Fixed.
Easy to forget, especially since we kn
Le 13/08/2009 03:30, Martin Buchholz a écrit :
Hi regex/String team,
We would like to contribute a performance improvement for Matcher.
Just a minor comment, there is not @since 1.7
Rémi
Please file a bug.
category: java_util_regex
Synopsis: Faster Matcher by replacing StringBuffer wit
The RFE#5066679 has been on my "next week's todo list" for a while:-) it
looks like
the Appendable might be a better choice here? I guess we should gain the
same performance
when you pass in a StringBuilder. Opinion?
Sherman
Martin Buchholz wrote:
Hi regex/String team,
We would like to con
Hi regex/String team,
We would like to contribute a performance improvement for Matcher.
Please file a bug.
category: java_util_regex
Synopsis: Faster Matcher by replacing StringBuffer with StringBuilder
Description:
The old Matcher API and implementation depend on the old StringBuffer class.
T
