Quantcast

String.ltrim() and rtrim() methods RFE

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

String.ltrim() and rtrim() methods RFE

Nick Radov

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 | 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

phil.race
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./

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Tim O'Brien
Administrator
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Nick Radov
In reply to this post by phil.race

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 <[hidden email]>
To: Nick Radov <[hidden email]>
Cc: [hidden email]
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./


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Stephen Colebourne-2
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 <[hidden email]>
> To: Nick Radov <[hidden email]>
> Cc: [hidden email]
> 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./
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

freddy33
The cost/benefit should be evaluated. And for this one the cost looks
very low. So...

On 11/16/07, Stephen Colebourne <[hidden email]> 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 <[hidden email]>
> > To: Nick Radov <[hidden email]>
> > Cc: [hidden email]
> > 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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Mark Reinhold
In reply to this post by Nick Radov
> Date: Fri, 16 Nov 2007 15:19:50 -0800
> From: Nick Radov <[hidden email]>

> 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.

Agreed.

> 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 the platform would be
a horrid, rotting mess of woefully inconsistent spaghetti.

Having said that, I've spent quite a bit of time over the last couple of
months hacking Python code for the OpenJDK Mercurial infrastructure, and
I've used Python's equivalent lstrip/rstrip functions more than once.
They're quite handy actually, especially the rstrip function that takes
a string argument and removes any trailing characters present in that
string.

So if somebody's going do to this I'd actually recommend adding four
methods (needed since Java doesn't have default parameter values):

    String.ltrim()
    String.ltrim(String charsToTrim)
    String.rtrim()
    String.rtrim(String charsToTrim)

Of course one can get this behavior today with the replaceFirst method,
e.g.,

    s.replaceFirst("[charsToTrim]+$", "")

but that requires compiling the regex and building a matcher, which is
awfully heavyweight, especially in the middle of a tight loop.

- Mark
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Patrick Wright
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 the platform would be
> a horrid, rotting mess of woefully inconsistent spaghetti.

It's nice to see you comment on this issue--I would like to hear
sometime (seems possibly related to governance) how smaller decisions
about the JDK (like this one) have been made in the past and will be
made in the future. Is it always a matter of responding to an RFE or a
bug? Who makes the decision, the respective group owners? Who keeps an
eye on the big picture? It somehow seems these sorts of changes fall
below the threshold of a JSR, but there's enough of this "tuning"
possible that it seems there should/could be some process for it as
well in order to achieve the both consistency in the result (across
the JDK) as well as encourage a "constant tuning" attitude to avoid
API rot.

I also note that in the projects I've worked on (as a contractor,
server side, for many years), as the other poster said, it's extremely
common for teams to either, a) roll their own convenience APIs, b) use
Apache commons or other friendly libraries. However, it would seem to
me that we could do better, if the community around JDK could agree on
convenience APIs that were perhaps not shipped with the JDK, but were
"blessed" as high-quality and recommended as "useful optional
libraries" and promoted as such.




Patrick
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Remi Forax
In reply to this post by Mark Reinhold
Mark Reinhold a écrit :

>> Date: Fri, 16 Nov 2007 15:19:50 -0800
>> From: Nick Radov <[hidden email]>
>>    
>
>  
>> 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.
>>    
>
> Agreed.
>
>  
>> 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 the platform would be
> a horrid, rotting mess of woefully inconsistent spaghetti.
>
> Having said that, I've spent quite a bit of time over the last couple of
> months hacking Python code for the OpenJDK Mercurial infrastructure, and
> I've used Python's equivalent lstrip/rstrip functions more than once.
> They're quite handy actually, especially the rstrip function that takes
> a string argument and removes any trailing characters present in that
> string.
>
> So if somebody's going do to this I'd actually recommend adding four
> methods (needed since Java doesn't have default parameter values):
>
>     String.ltrim()
>     String.ltrim(String charsToTrim)
>     String.rtrim()
>     String.rtrim(String charsToTrim)
>  
we don't have default values but we have varargs :)
so we can mimic python lstrip/rstrip using only two methods:

     String.ltrim(char... charsToTrim)
     String.rtrim(char... charsToTrim)

If the array charsToTrim is empty or null, whitespace characters are used.

> Of course one can get this behavior today with the replaceFirst method,
> e.g.,
>
>     s.replaceFirst("[charsToTrim]+$", "")
>
> but that requires compiling the regex and building a matcher, which is
> awfully heavyweight, especially in the middle of a tight loop.
>
> - Mark
>  
Rémi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: String.ltrim() and rtrim() methods RFE

Nick Radov
In reply to this post by Mark Reinhold

It seems we have general consensus that the ltrim() and rtrim() methods should be added, and possibly some other related methods as well. Now, how do we go about reopening Bug ID: 4074696 <http://bugs.sun.com/view_bug.do?bug_id=4074696>? Who has authority to make decisions on those issues?

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: Mark Reinhold <[hidden email]>
To: Nick Radov <[hidden email]>
Cc: [hidden email]
Date: 11/16/2007 08:16 PM
Subject: Re: String.ltrim() and rtrim() methods RFE





> Date: Fri, 16 Nov 2007 15:19:50 -0800
> From: Nick Radov <[hidden email]>

> 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.

Agreed.

> 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 the platform would be
a horrid, rotting mess of woefully inconsistent spaghetti.

Having said that, I've spent quite a bit of time over the last couple of
months hacking Python code for the OpenJDK Mercurial infrastructure, and
I've used Python's equivalent lstrip/rstrip functions more than once.
They're quite handy actually, especially the rstrip function that takes
a string argument and removes any trailing characters present in that
string.

So if somebody's going do to this I'd actually recommend adding four
methods (needed since Java doesn't have default parameter values):

   String.ltrim()
   String.ltrim(String charsToTrim)
   String.rtrim()
   String.rtrim(String charsToTrim)

Of course one can get this behavior today with the replaceFirst method,
e.g.,

   s.replaceFirst("[charsToTrim]+$", "")

but that requires compiling the regex and building a matcher, which is
awfully heavyweight, especially in the middle of a tight loop.

- Mark

Loading...