If you allow entry of filename and then search for the files, you'll have to be ready to handle multiple files with the same name. (ie, programs/java/foo.java and programs/java/bar/foo.java) An easier task would be to ask the user to operate a standard file chooser, where they have to actually specify a path to the file. This is already available in Swing, or you could implement it yourself if you want.
Also, I imagine that it would make sense to just check the return from reading the nextLine() (of whatever input method you favor). If it's not null, increment your pointer and move one, no need to read the file into memory for the application as described. You might have a future expansion of the application in mind, though, or you might want to do it for its own sake, both respectable reasons to do this, but there's no need for what you're describing.
All in all, this looks like a solid plan of attack for the basic project you're describing.
If you want to get fancy, try to report back some facts about the file: number of lines, number of uncommented lines, number of methods. Average number of lines per method. Number of fields declared in this class, their names, and what sort of access they have. That sort of thing. You should be able to do all of these without loading the whole file into memory. They'll all require that you learn a bit of parsing, which is worth doing.