Lang-1345 Enhance non-empty strings

[ThrawnCA]

No description provided.

[coveralls]

Coverage decreased (-0.2%) to 94.9% when pulling 3ec23f1 on ThrawnCA:LANG-1345-enhance-non-empty-strings into f692351 on apache:master.

[garydgregory]

I really do not like the method names starting with "extend". It does not smell right to me. We have some methods here that start with "default", maybe that's better.

[stokito]

For me is not clear importance of the new methods. I can't remember situations when I needed for something like this. And even if I need something like this I'll write the function myself and I'll not even think about to search something in Commons Lang library. Time spent to looking for the method will be ten time more then write myself.
Maybe commons lang itself uses the function internally then it can make sense.

It would be great if you can give us an examples of usage and how they are important.

[ThrawnCA]

A typical case would be that you're assembling a sentence, and if a component is not empty, you need to add a space beforehand. (Sometimes join will handle this, but other times it's not the right tool for the situation.)

Or you're building a URL, and if there's a non-blank query string, you need to put a question mark before it.

Really, any situation where part of a string is optional but requires special formatting if present.

@garydgregory The trouble with "default" names is that this functionality is the opposite. The defaultXXX methods have the logic, "if present, leave untouched; otherwise use the second parameter." This would instead be, "if present, apply the second parameter; otherwise, leave untouched." Could use "appendIfNotXXX" and "prependIfNotXXX" I suppose, but I'd rather combine prefixes and suffixes in one method.

[aaabramov]

Could use "appendIfNotXXX" and "prependIfNotXXX" I suppose, but I'd rather combine prefixes and suffixes in one method.

I think this naming would be better and more granular.

[ThrawnCA]

And I've come across another situation where I want this: assembling a filename from customer name parts, and adding a separator for middle name if (and only if) it's provided.

[RahulNagekar]

Looks good.

[ThrawnCA]

Bump. I believe I've addressed the changes that were requested.

[ThrawnCA]

Just came across another use case for this. One of our systems is retrieving customer email addresses, if provided, and decorating them with the customer's name, eg John Smith <john.smith@example.com>. If there is no email address, then it should return an empty string, rather than John Smith <>.