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 impact. Nick's observation is tru: > 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. I've worked on Commons Lang, but I have to tell you that it is an ongoing embarrassment that every Java program ever developed has to either include a set of static methods or reimplement low-level String parsing functions because Sun just doesn't think it is a big idea. If Java had open classes this really wouldn't be such a big deal. On 11/13/07, Phil Race <[EMAIL PROTECTED]> wrote: > > 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./ > > -- ------ Tim O'Brien: (847) 863-7045
