String.ltrim() and rtrim() methods RFE

[Nick Radov]

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 are left 
to languish.

Let's look at this RFE a different way. Is there any reason not to 
implement it? All of the necessary functionality is already present in the 
trim() method. We just need to break it out into two public ltrim() and 
rtrim() methods.

Microsoft's .NET 3.5 framework has equivalent methods on the System.String 
class as TrimStart and TrimEnd. Don't we want to keep Java competitive 
with .NET?
<
http://msdn2.microsoft.com/en-us/library/system.string_methods(VS.90).aspx
>

Nick Radov · Research & Development Manager · Axolotl Corp
www.axolotl.com o: 650.964.1100 x 116
800 West El Camino Real Suite 270 Mountain View CA 94040
 
Frost and Sullivan Awards | Market Leadership | Business Development 
Strategy Leadership
 
The information contained in this e-mail transmission may contain 
confidential information. It is intended for the use of the addressee. If 
you are not the intended recipient, any disclosure, copying, or 
distribution of this information is strictly prohibited. If you receive 
this message in error, please inform the sender immediately and remove any 
record of this message.



From:
Phil Race <Phil.Race at Sun.COM>
To:
Nick Radov <nradov at axolotl.com>
Cc:
core-libs-dev at openjdk.java.net
Date:
11/13/2007 07:58 PM
Subject:
Re: String.ltrim() and rtrim() methods RFE



Nick,
I note this has just two customer records and just a single  jdc vote 
despite having over eight years to
accumulate these whilst it was open, whereas popular issues quickly 
accumulate hundreds of votes.
Furthermore only one person has found it important enough to comment in 
the bug parade comments.
So I think you'd need to show that its a lot more widely needed than 
some low single digits number
of developers.

-phil.


Nick Radov wrote:
>
> I would like to reopen discussion of Bug ID: 4074696 
> <http://bugs.sun.com/view_bug.do?bug_id=4074696> for possible 
> inclusion in jdk7. It seems to me that RFE was prematurely closed 
> without proper consideration. Many developers have needed to left or 
> right trim a String and I'm sure that same code has been rewritten 
> thousands of times in applications. It would really help to have them 
> in the standard library, and the impact on compiled file size would be 
> minimal. The evaluation reason giving for closing the bug was "You can 
> write this yourself and get reasonable performance with a modern VM." 
> Well, of course we can get reasonable performance, but that isn't 
> really the point. The reason for adding those methods to the standard 
> library is to reduce the amount of redundant, low-level code that 
> application developers have to write. Having to write those methods 
> ourselves in applications also forces the creation of 
> "StringUtilities" classes with a variety of static methods, which 
> somewhat defeats the purpose of OO design.
>
> If we can get this reopened I would be happy to take care of making 
> the actual code changes. I just requested the Developer role on the 
> jdk project so hopefully that will be approved soon.
>
> *Nick Radov · Research & Development Manager · Axolotl Corp*
> www.axolotl.com o: 650.964.1100 x 116
> 800 West El Camino Real Suite 270 Mountain View CA 94040
> 
> Frost and Sullivan Awards | _Market Leadership_ 
> <http://www.axolotl.com/press/20060626a/> | _Business Development 
> Strategy Leadership_ <http://www.axolotl.com/press/20060626b/>
> 
> /The information contained in this e-mail transmission may contain 
> confidential information. It is intended for the use of the addressee. 
> If you are not the intended recipient, any disclosure, copying, or 
> distribution of this information is strictly prohibited. If you 
> receive this message in error, please inform the sender immediately 
> and remove any record of this message./ 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20071116/b7bc174b/attachment.html>