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 > > 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 <[EMAIL PROTECTED]> > > To: Nick Radov <[EMAIL PROTECTED]> > > Cc: core-libs-dev@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./ > > > > > -- http://freddy33.bglogspot.com/ http://www.jfrog.org/
