#General Remarks#

The code checks incoming parameters, and throws an IllegalArgumentException when they are out of bounds (except nthCol; see later). This is a good thing. It would be even better if you could include the faulty indices in the error message so that I don't have to pop out the debugger. ;-)

The class seems to work with 1-based indices rather than 0-based, the latter being more common in Java^[1]. As you commented about this within your code (but not in your public documentation), you've felt there's a mismatch; it may be better to use 0-based indices for consistency with the rest of the JDK.

You're going through hoops to work with arrays in the public interface while using streams and collections behind the scenes. Consider returning lists instead of arrays, or maybe even streams if you're so inclined.

#Constructors#

Character encodings are important, too important to force the default encoding on your users, for any definition of 'default encoding'. Many of the classes and methods deprecated in java.io were so because they assumed about encodings, which I've seen lead to subtle but no less spectacular breakage.^[2] Allow/force your users to specify the encoding. If they make it be this fangled default encoding, then on their heads be it. (A simular argument could be made for Paths.get.)

For your class, it doesn't matter how it gets its stream of strings, as long as it gets it. Make this clear in your constructor:

Txt(Supplier<? extends Stream<String>> stream, Pattern delimiter) {
 this.stream = stream;
 this.delimiter = delimiter;
}

No fuss about encodings, file paths, IOExceptions, invalid patterns... Just the bare needs to function. Any other constructors or static factory methods you desire are then for convenience, and should delegate to this one.

#Specifics#

nthCol(int) breaks with the other methods in that it tries to fix an erroneous input parameter. This leads to the oddness of nthCol(0) succeeding but cols(0, 0) failing. Consistency is king in library usage: nthCol should fail, or cols should succeed.^[3]

[!] cols(int[]) changes the contents of the incoming array. You don't really need to sort this array, anyway: I'd consider it a feature if the columns returned are in the same order that I requested them.

Txt is not a very descriptive name. ;-) Consider names such as LineSplitter or TextTable.

^{[1] Oh, how sweetly I loathe you, java.sql, for your 1-based indexing.}

^{[2] Fixed record length + multi-byte encoding + JNI. It was glorious.}

^{[3] Personally, I lean towards "fail early, fail hard," (i.e. throw) but this depends on your intended audience.}

General Remarks

The code checks incoming parameters, and throws an IllegalArgumentException when they are out of bounds (except nthCol; see later). This is a good thing. It would be even better if you could include the faulty indices in the error message so that I don't have to pop out the debugger. ;-)

The class seems to work with 1-based indices rather than 0-based, the latter being more common in Java^[1]. As you commented about this within your code (but not in your public documentation), you've felt there's a mismatch; it may be better to use 0-based indices for consistency with the rest of the JDK.

You're going through hoops to work with arrays in the public interface while using streams and collections behind the scenes. Consider returning lists instead of arrays, or maybe even streams if you're so inclined.

Constructors

Character encodings are important, too important to force the default encoding on your users, for any definition of 'default encoding'. Many of the classes and methods deprecated in java.io were so because they assumed about encodings, which I've seen lead to subtle but no less spectacular breakage.^[2] Allow/force your users to specify the encoding. If they make it be this fangled default encoding, then on their heads be it. (A simular argument could be made for Paths.get.)

For your class, it doesn't matter how it gets its stream of strings, as long as it gets it. Make this clear in your constructor:

Txt(Supplier<? extends Stream<String>> stream, Pattern delimiter) {
 this.stream = stream;
 this.delimiter = delimiter;
}

No fuss about encodings, file paths, IOExceptions, invalid patterns... Just the bare needs to function. Any other constructors or static factory methods you desire are then for convenience, and should delegate to this one.

Specifics

nthCol(int) breaks with the other methods in that it tries to fix an erroneous input parameter. This leads to the oddness of nthCol(0) succeeding but cols(0, 0) failing. Consistency is king in library usage: nthCol should fail, or cols should succeed.^[3]

[!] cols(int[]) changes the contents of the incoming array. You don't really need to sort this array, anyway: I'd consider it a feature if the columns returned are in the same order that I requested them.

Txt is not a very descriptive name. ;-) Consider names such as LineSplitter or TextTable.

^{[1] Oh, how sweetly I loathe you, java.sql, for your 1-based indexing.}

^{[2] Fixed record length + multi-byte encoding + JNI. It was glorious.}

^{[3] Personally, I lean towards "fail early, fail hard," (i.e. throw) but this depends on your intended audience.}