This is not much of a question, but a discussion and searching for opinions. I have seen that many use the Scanner class for getting input from the keyboard. Some, like myself, use the BufferedReader.

Why will someone use one over the other?

Or they both do the same thing when it comes something simple as that and their real difference is when it comes to using them for something more complex?

Recommended Answers

All 14 Replies

Well im voting for the scanner. Thats how i learnt and thats how i go, i dont find anything wrong with it so i stay that way.. addmitedly i really dont know a thing about Buffered Reader anyway, so it could be loads better for all i know.

Well im voting for the scanner. Thats how i learnt and thats how i go, i dont find anything wrong with it so i stay that way.. addmitedly i really dont know a thing about Buffered Reader anyway, so it could be loads better for all i know.

Ditto... If i ever begin to study BufferedReader I'll discuss it further. What are the differences anyway? Any one that is advanced plz reply?

Neither one. I don't write console applications. :P

Ehmmm where do I find this in Java Microedition? :?:

Neither me. For now I work in JME, Swing or Web Development so no.

I used to use the buffered reader in September but I started to find when in my contests that the Scanner is better.

Since I can read individual elements at a time, I don't have to worry about splitting and parsing into integers.

Say my input file is:

4 4
*...
....
.*..

With the buffered reader, I would have to read things in line at a time, split it up and parse it into integers. Thus the buffered reader seems to make input a lot tougher.

Buffered reader:

BufferedReader br = new BufferedReader(new FileReader("DATA1.txt"));
String[] arsNums = br.readLine().split(" ");
int nX = Integer.parseInt(arsNums[0]);
int nY = Integer.parseInt(arsNums[1]);

With the scanner I don't have to read in each line as a string and parse it with the Integer class.

Scanner:

Scanner sin = new Scanner(new FileReader("DATA1.txt"));
        int nX = sin.nextInt();
        int nY = sin.nextInt();
        char[][] arcGrid = new char[nX][nY];
        String sLine = "";

        for (int x=0;x<nX;x++) {
            sLine = sin.next();
            for (int y=0;y<nY;y++) {
                arcGrid[x][y] = sLine.charAt(y);
            }
        }

Also I can have Scanner that parses each individual element in a String. So the Scanner class is quite helpful - and in my opinion a lot better than the buffered reader.

String sText = "Four men went down to the store, to catch frogs!";
Scanner sin = new Scanner(sText);
while (sin.hasNext()) {
        System.out.println(sin.next());
}

Prints:

Four
men
went
down
to the
store,
to
catch
frogs!

So that is why I believe the Scanner class is better than the Buffered Reader.

Neither one. I don't write console applications. :P

I don't write console applications either but when I first begun I knew from my book only the BufferedReader. So since we've seen many students here asking how to read files and input from the console I thought to get other opinions and discuss the topic.

There has to be some reason why someone would choose to use one over the other

I guess it's just the matter of what you like, and on which is a lot easier. I have learn buffered reader. My prof. didn't teach us scanner. I heard about it from others that it is much easier to use, but i don't know. My prof. doesn't allow us to use scanner. I don't know why.

I don't write console applications either but when I first begun I knew from my book only the BufferedReader.

That was most probably because when we learnt Java, java.util.Scanner did not exist.
I started learning Java from the 1.4.2 version of the JDK, and Scanner was introduced only in the 1.5 version and since console input is not so widely used by many of us, we opted to stick with good ol' BufferedReader.

That was most probably because when we learnt Java, java.util.Scanner did not exist.
I started learning Java from the 1.4.2 version of the JDK, and Scanner was introduced only in the 1.5 version and since console input is not so widely used by many of us, we opted to stick with good ol' BufferedReader.

Well the book I had was called Java 1.2. I don't remember what kind of java I had because I didn't know about versions but I believe I had Java Version 1.2

Well the book I had was called Java 1.2. I don't remember what kind of java I had because I didn't know about versions but I believe I had Java Version 1.2

Exactly that explains the reason why like myself you too have opted for the BufferedReader, Scanner just never existed during our initial console programming days in Java.

IMO Scanner is much more than just another I/O class with a pretty interface/API; it has advanced parsing capabilities which attempts to remove the utility class most programmers create to process the strings read in by a normal reader. It is pretty much capable of reading and performing complicated processing on strings irrespective of the source [Strings, InputStreams, Readers]. The feature of skipping/locating patterns based on regular expressions is powerful in itself.

On the other hand, the API specifies that the BufferedReader class *should* provide buffering capabilities, something not mandated when implementing a Scanner .

To conclude it all, I still end up using BufferedReader and my custom string processor when reading and processing textual data. Nothing against Scanner mind you, just historical reasons. :-)

commented: That's the comment I was looking for +5

Seeing as this is the first post that comes up when you search for "bufferedreader scanner java" in google, it's worth posting a correct answer. A bufferedreader is exactly that, something that buffers. If you are reading in from a file, using a bufferedreader will give you a speed improvement. However, if you are reading in from the terminal (i.e. user input), there is essentially no difference. Use whatever strikes your fancy. What I do:

1. If reading in from the terminal, scanner, because it's easier.
2. If reading in from a file, bufferedreader, because it's faster.

> 2. If reading in from a file, bufferedreader, because it's faster.

That's a non-issue unless you are reading a lot of pretty big files. For reading one-off files in an application (which are around a few KiB's), I go with Scanner just because it's less typing.

An implementation detail which the users of Scanner class need to keep in mind is that it is memory/cpu heavy (at least when compared to BufferedReader) because it internally uses "regular expressions" for matching your "nextXXX" as opposed to just reading everything till the end of line as in the case of a regular Reader.

Scanner is the better option.

Also because it has a lot more methods including the boolean methods to check a wide range of input types before to you begin implementing a certain function. As well as pattern matching and find in line, etc.

It's a lot more easier to use.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.