• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why FileInputStream Necessary over Scanner To Read A File  RSS feed

 
Recaip Sanli
Ranch Hand
Posts: 72
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need to read from two .txt files. Instuctuons I have says:
"To do this, you will use the FileInputStream class. Why is it necessary to use the FileInputStream class instead of the Scanner class?"


Why is it necessary to use FileInputStream class to read file object?
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please tell us where that information comes from. I think it is incorrect, and you do not need a file input stream. For text files use classes with reader or writer in their names. In fact, a file input stream is not the correct class to use for a text file. Have a look at the Java™ Tutorials. If you use a Scanner on a text file you will write something like this:-The two lines with comments // ;-) will need to be changed. The try(...) construct is called try with resources and that link explains that it automates the closing of the file after use.
 
Recaip Sanli
Ranch Hand
Posts: 72
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Please tell us where that information comes from. I think it is incorrect, and you do not need a file input stream. For text files use classes with reader or writer in their names. In fact, a file input stream is not the correct class to use for a text file. Have a look at the Java™ Tutorials. If you use a Scanner on a text file you will write something like this:-The two lines with comments // ;-) will need to be changed. The try(...) construct is called try with resources and that link explains that it automates the closing of the file after use.


Thank you @Campbell Ritchie.

My teacher said for this assignment it's not possible to use scanner so that's why we are using FileInputStream. I was not able to find a quite reasoning why FileInputStream must be used to read a txt file.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recaip Sanli wrote:
My teacher said for this assignment it's not possible to use scanner so that's why we are using FileInputStream. I was not able to find a quite reasoning why FileInputStream must be used to read a txt file.


There is zero reason to not be able to use a Scanner for a text file. After all, that is what it is designed to parse. However, if it was a binary file, then yeah, it would make sense. The Scanner class doesn't work very well for binary files, and depending on the values, arguably, may not be able to work at all.

Alternatively, from a course perspective, your instructor may also just want you to learn the FileInputStream class.

Henry
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recaip Sanli wrote:My teacher said for this assignment it's not possible to use scanner so that's why we are using FileInputStream. I was not able to find a quite reasoning why FileInputStream must be used to read a txt file.

As others have said: there is no Java reason to use a FileInputStream, but it's possible that your teacher is trying to show you how InputStreams and Readers "fit together" from the ground up.

For example: You can get a Reader from an InputStream by wrapping it in an InputStreamReader, viz:
  InputStreamReader isr = new InputStreamReader(myFileInputStream);
and you can then "buffer" that Reader by wrapping it in a BufferedReader, viz:
  BufferedReader br = new BufferedReader(isr);
which then allows you to read whole "lines" in at once, rather than single bytes or characters.

Having all these different "levels" of something that is basically a "byte provider" probably seems a bit confusing at the moment - it confused the heck out of me too when I was starting out - but there is a good reason for it - primarily because it makes building specialised streams very simple ... even if it doesn't seem like it at the moment.

So I suspect your teacher is simply trying to show you how Java's "stream" objects work from ground zero ... but it's just a guess.

Winston
 
Liutauras Vilda
Sheriff
Posts: 4927
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can look at the website too, it nicely demonstrates different ways of reading files, covers what was mentioned in this thread.
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Under the ancien régime, you had to write:-Then you found out you had to put try catch and finally around everything because all those methods declare checked Exceptions. But you never needed any classes ending Stream.

You had to use an InputStreamReader for System.in, but that class name ends Reader. You don't need to combine file input streams with Scanner. I think you can combine a file reader with Scanner, but that is a different story:-
Scanner fileScan = new Scanner(new FileReader(new File("myFile.txt")));
I think there is some confusion creeping in here, but if you have been told to use FileInputStream and can't persuade your teacher otherwise, you are stuck with it. The Java™ Tutorials link I posted yesterday says quite clearly to use classes ending Reader for text file and classes ending Stream for binary files.

As Henry implies, the program will go wrong much faster if you use Scanner/XYZReader for a binary file. System.in and System.out are instances of InputStream and PrintStream but they are standalone classes, so they are different; forget they have Stream in their names. Also forget the newer Stream and XYZStream classes in Java8; they are different too.

You will find this in this Java™ Tutorials section, part of what I linked yesterday:-
CopyBytes seems like a normal program, but it actually represents a kind of low-level I/O that you should avoid. Since xanadu.txt contains character data, the best approach is to use character streams, as discussed in the next section.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!