On 04/07/2014 07:00 PM, Xueming Shen wrote:
On 04/04/2014 10:08 AM, Xueming Shen wrote:
On 4/3/14 4:43 PM, Jeremy Manson wrote:
Good catch, thanks.
I think we should probably just go with the (equivalent to the)
StringBuffer variant. I'm pretty loathe to modify the StringBuilder
directly if
On 04/04/2014 10:08 AM, Xueming Shen wrote:
On 4/3/14 4:43 PM, Jeremy Manson wrote:
Good catch, thanks.
I think we should probably just go with the (equivalent to the) StringBuffer
variant. I'm pretty loathe to modify the StringBuilder directly if we are
going to back that change out.
Do yo
On 4/3/14 4:43 PM, Jeremy Manson wrote:
Good catch, thanks.
I think we should probably just go with the (equivalent to the)
StringBuffer variant. I'm pretty loathe to modify the StringBuilder
directly if we are going to back that change out.
Do you want me to generate a new patch?
I can/w
On 03/25/2014 02:07 PM, Jeremy Manson wrote:
Okay. Thanks, Sherman. Here's an updated version.
I've diverged a bit from Peter's version. In this version,
appendExpandedReplacement takes a StringBuilder. The implications is that In
the StringBuilder case, it saves creating a new StringBuild
let's add the StringBuilder method(s), if you can provide an updated
version, I can run the rest (since it's
to add new api, there is an internal CCC process need to go through).
-Sherman
On 3/21/14 5:18 PM, Jeremy Manson wrote:
So, this is all a little opaque to me. How do we make the go/no-g
2009? I do have something similar back to 2009 :-)
http://cr.openjdk.java.net/~sherman/regex_replace/webrev/
Then the ball was dropped around the discussion of whether or not
the IOE should be thrown.
But if we are going to/have to have explicit StringBuilder/Buffer pair
anyway, then we can kee
On 03/19/2014 06:51 PM, 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
Hi Jeremy,
Your factoring-out of expandReplacement() method exposed an opportunity
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
