A simple text import can fail without producing an obvious parsing error. The application receives a line, splits it into fields, and discovers fewer values than expected. The missing value may have been an empty field at the end of the line.
Java’s String.split behavior makes this an important boundary case. Before choosing an overload, establish whether empty fields represent meaningful positions in your input format. A blank optional value and an absent column may require different handling.
Choose the limit deliberately
The one-argument split method uses behavior equivalent to a limit of zero, which discards trailing empty strings. A negative limit preserves them. A positive limit restricts the number of splits and leaves the remaining input in the last array element.
Consider this deliberately simple, unquoted record:
String record = "A17,active,";
String[] compact = record.split(",");
String[] complete = record.split(",", -1);The first result contains two fields. The second contains three, with an empty string in the final position.
Suppose the agreed layout is identifier, status, and optional comment. The third position still exists when the comment is blank. Preserving it allows the importer to distinguish that valid record from a line that never supplied the third field.
Remember that the separator is a regular expression
The first argument to split is a regular expression. Characters with special regex meanings need appropriate treatment when the intended separator is literal.
For a configurable delimiter, Pattern.quote produces a pattern that matches the supplied text literally. The Pattern API documents this behavior explicitly.
For example:
import java.util.regex.Pattern;
String delimiter = "|";
String record = "A17|active|";
String[] fields = record.split(Pattern.quote(delimiter), -1);This example expresses two independent decisions: the vertical bar is a literal delimiter, and trailing empty fields must remain in the result.
Keeping those decisions visible makes the code easier to review. A future change from a comma to a different separator should not silently change how the parser interprets that separator.
Validate the structure after splitting
Preserving empty values does not prove that a record is valid. Check the expected field count before reading positions, then validate each field according to its role.
For the three-field example, reject an unexpected fourth field rather than quietly ignoring it. Check that the identifier is present, that the status belongs to the accepted set, and that a blank comment is allowed.
Useful test cases include a normal record, an empty final field, an empty middle field, too many fields, and too few fields. Give each case an expected outcome. This makes the format’s rules explicit instead of letting incidental library behavior define them.
Keep CSV parsing separate
Real CSV can contain quoted commas, embedded line breaks, and escaped quotation marks. RFC 4180 describes these conventions. Splitting each line at every comma cannot represent those cases correctly.
Use String.split for a format whose rules are genuinely simple and controlled. For CSV exchange, choose a parser that understands the required dialect.
The engineering decision begins with the input contract. Once that contract says what empty values, quoting, and delimiters mean, the implementation can preserve those meanings reliably.