String.ltrim() and rtrim() methods RFE

[Stephen Colebourne]

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 JDK class and work through them one by one, considering 
what needs adding (by evaluating open and closed source libraries, and 
taking the most common)

Any JSR does need to be very open though, and it needs to be supported 
by (and funded by) a major company, probably Sun.

Stephen

Nick Radov wrote:
> 
> 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_ 
> <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./
> 
> 
> 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./
> 
>