The source file is TextReader.java and the documentation is TextReader.html.
Let me say a few words about the philosophy behind the code. I want to provide a simple set of utilities. I've tried to avoid the temptation to offer too much. At the same time, I want to provide a complete set of primitives that could be used to build more complex tools. I believe I've done that. In fact, along these lines I almost made the method skipWhite a private method. I wrote it for myself to implement the TextReader class, not as a general-purpose utility. One could easily write it from primitive operations. So I wouldn't mind seeing it go. I included it mostly because I found it so useful that I thought it was worth the added complexity to include it.
I might conclude that the utilities for specifying that end-of-line is significant are not worth having. They are confusing to understand, but quite powerful when you know how to use them. I can provide examples if anyone is interested.
I've tried to strike a reasonable compromise with Java conventions. The standard input classes are difficult to use because they throw so many exceptions that must be handled in some manner. Most textbooks recommend just adding "throws IOException" to method main and any other method that does reading, but that's a terrible solution. It's confusing to students and it makes the exception handling mechanism meaningless.
On the other hand, when you're reading from a reliable input stream like System.in, the exceptions often don't make sense. I haven't found a way to get an IOException when reading from System.in (if anyone out there knows how to generate the exception, please let me know). It's quite different if your input stream is over a network and the connection might be lost. But with these stable streams, it seems silly to worry about exceptions that will never occur. That's why I begin the TextReader documentation with the statement that it should be used only with stable streams like System.in. If some programmer uses it for an unstable stream, then it's the programmer's fault. And by convention, you should throw a RuntimeException when it's the programmer's fault. So that's what I do. I translate all IOExceptions into RuntimeExceptions. Because they become RuntimeExceptions, they do not have to be explicitely handled. They can, however, be handled if one wants to.
My original version of this class included a constructor that took a file name as a string. I might be convinced to put that back in, but it seemed to be going too far in the direction of handling errors for the programmer. When opening an external input file there are legitimate potential errors that should be handled.
In my own course I often have students redirect input from the command prompt. For example, I might have them say:
In this case the input comes in as System.in, so you don't need to do anything special with try/catch. It also allows the student to hand test the program with console input by saying:java Prog3Main < prog3.dat
They would then type various lines of input to see how the program behaves. The user can simulate end-of-file by typing a special character by itself on a blank line (in unix you type control-d, in dos you type control-z).java Prog3Main