[LANG-1593] Common behavior for StringUtils join APIs when called with char or String delimiter#784
[LANG-1593] Common behavior for StringUtils join APIs when called with char or String delimiter#784HubertWo wants to merge 28 commits into
Conversation
| * @since 3.13.0 | ||
| */ | ||
| public static String join(final char[] elements, final String separator) { | ||
| return elements == null ? null : join(elements, separator, 0, elements.length); |
There was a problem hiding this comment.
The null checks in these methods are superfluous as the join method called already checks for the same condition. Less boilerplate is better IMO.
There was a problem hiding this comment.
- The method is public - so users may pass
nullaselementswhich will causeNPEin the same lineelements.length
assertNull(StringUtils.join((char[]) null, "-")); // throws NPE if null check is removed
- This case was not tested, so I added additional assertions in tests to cover it.
| assertEquals("foo2", StringUtils.join(MIXED_TYPE_LIST)); | ||
| } | ||
|
|
||
| @Disabled |
There was a problem hiding this comment.
Was this test removed because the code is already covered elsewhere? Did you confirm this by looking at the JaCoCo report?
There was a problem hiding this comment.
|
@HubertWo |
|
I just think it use too many |
| assertNull(StringUtils.join((short[]) null, SEPARATOR_CHAR, 0, 1)); | ||
| assertEquals(StringUtils.EMPTY, StringUtils.join(SHORT_PRIM_LIST, SEPARATOR_CHAR, 0, 0)); | ||
| assertEquals(StringUtils.EMPTY, StringUtils.join(SHORT_PRIM_LIST, SEPARATOR_CHAR, 1, 0)); | ||
| assertEquals("1,2", StringUtils.join(SHORT_PRIM_LIST, SEPARATOR)); |
There was a problem hiding this comment.
@HubertWo
The point of String vs char separators is that a String can be longer than one character, so you should test for String separators longer than one character to make sure the right work takes place under the covers.
There was a problem hiding this comment.
Sorry for the late reply, I was on vac.
I will take a look on your comments and try to apply changes later this week.
There was a problem hiding this comment.
The joining part is done via java.util.StringJoiner with accepts onlyCharSequence in constructor, so it's made to use more than one character as separator by default. Don't you think that testing that would be redundant?
|
@XenoAmess |
|
@garydgregory looks like I've addressed all the questions. |
|
@garydgregory BUMP |
Hi. I find some time today for this question (finally).
This statement be correct, but also be where I worried about performance. Please look at the sources in JDK, where In short, for basic types, should not convert them to String, but use StringBuilder directly, will bring far better performance. BUT I just foundout that you did not bring this issue, this issue is already in commons-lang before your pr. So I will not stop you from merging this in, but still I will find time to refactor the whole |
I was not aware of that. Thank you for your time @XenoAmess . Update: |

Added dedicated
StringUtils.joinmethods for all Java primitives.All new methods accept String as a delimiter.
From now on, old methods StringUtils.join which accept char as delimiter internally use
String.valueOf(delimiter).I have added addition test cases.