commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 24911] - last substring returned by StringUtils.split( String, String, int ) is too long
Date Sat, 22 Nov 2003 23:52:49 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24911>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24911

last substring returned by StringUtils.split( String, String, int ) is too long





------- Additional Comments From phil@steitz.com  2003-11-22 23:52 -------
I don't understand what the problem is.  The following tests (taken from your
patch, eliminating the added boolean parameter) succeed with the current code:

String stringToSplitOnNulls = "ab   de fg" ;
        String[] splitOnNullExpectedResults = { "ab", "de", "fg" };
        
        String[] splitOnNullResults = StringUtils.split( "ab   de fg", null);
        assertEquals(splitOnNullExpectedResults.length, splitOnNullResults.length);
        for (int i = 0 ; i < splitOnNullExpectedResults.length ; i+= 1) {
            assertEquals(splitOnNullExpectedResults[i], splitOnNullResults[i]);
        }
        
        String[] expectedResults = { "ab", "de fg" };
        splitOnNullResults = StringUtils.split( "ab   de fg", null, 2);
        assertEquals(expectedResults.length, splitOnNullResults.length);
        for ( int i = 0 ; i < expectedResults.length ; i+= 1 ) {
            assertEquals(expectedResults[i], splitOnNullResults[i]);
        }

Looks to me like the current code is functioning as advertised. See the example
in the javadoc:

StringUtils.split("ab:cd:ef", ":", 2)    = ["ab", "cdef"]

Probably should add your example, which shows that in the case of a whitspace
delimiter, the delimiter is not stripped from the terminal segment.

I would not support changing this behavior, since this would change the
contract.  It might be a good idea, however, to drop the javadoc reference to
the StringTokenizer.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message