Hi Mark
> > Let's look at this RFE a different way. Is there any reason not to
> > implement it?
>
> Beware: In general this is not a very persuasive line of reasoning.
>
> If all RFEs over the last ten years had been evaluated in this way then
> most of them would've been implemented by now, and
> Date: Fri, 16 Nov 2007 15:19:50 -0800
> From: Nick Radov <[EMAIL PROTECTED]>
> The bug voting mechanism doesn't really work for trivial RFEs like this.
> First, the bug has been closed for a while and no one is going to vote for
> a closed bug. Second, everyone only gets a few votes so they're g
The cost/benefit should be evaluated. And for this one the cost looks
very low. So...
On 11/16/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> There is some talk of adding a group of new methods to low level
> classes: http://smallwig.blogspot.com/2007/11/minor-api-fixes-for-jdk-7.html
>
> Per
There is some talk of adding a group of new methods to low level
classes: http://smallwig.blogspot.com/2007/11/minor-api-fixes-for-jdk-7.html
Personally, I would like to see this extended to become a simple JSR
where ideas such as ltrim/rtrim and so on can be evaluated properly.
ie. take each J
Phil,
The bug voting mechanism doesn't really work for trivial RFEs like this.
First, the bug has been closed for a while and no one is going to vote for
a closed bug. Second, everyone only gets a few votes so they're going to
put their votes on the most critical issues. Annoyances like this ar
ltrim and rtrim are excedingly useful. I've often wondered why Sun didn't
bother to include them. It is just another one of those reasons why people
tend to say that string manipulation in Java leaves much to be desired.
This should take all of two minutes to implement, and has a sub-trivial
imp
