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