Why doesn't the Scanner class have a nextChar method?

Question

This is really curiosity more than a problem ...

Why doesn't the Scanner class have a nextChar() method? It seems like this should happen when you consider that it has next , nextInt , nextLine , etc. Method.

I understand you can just do the following:

 userChar = in.next().charAt(0); System.out.println( userChar ); 

But why not use the nextChar() method?

Answer 1

The reason is that the Scanner class is designed to be read in tokens, separated by spaces. This is a convenience class that wraps the underlying input stream. Before the scanner, everything you could do was read in bytes, and this is a big pain if you want to read words or lines. With Scanner, you pass System.in and perform a series of read () operations to tokenize the input for you. Reading a single character is a simpler operation. Source

You can use (char) System.in.read(); .

Answer 2

According to javadoc a Scanner doesn't seem to be designed to read single characters. You attach a Scanner to an InputStream (or something else) and it parses the input for you. It can also cut unwanted characters. This way you can easily read numbers, strings, etc. If you only need characters from your input, use InputStreamReader , for example.

Answer 3

The Scanner class is the basis for the logic implemented in the String next(Pattern) method. An additional API method, for example nextDouble() or nextFloat() . Provide a template inside.

Then the class description says :

A simple text scanner that can parse primitive types and strings using regular expressions.

The scanner splits its input into tokens using the delimiter pattern, which by default matches a space. As a result, tokens can be converted to values ​​of different types using the various following Methods.

From the description, it may be sad that someone forgot about char, since it is a primitive type.

But the concept of a class is to find patterns, char doesn't have a pattern, it's just the next character. And this logic IMHO caused the fact that nextChar was not implemented.

If you need to read char file on char, you can use a more efficient class.

Answer 4

I would suggest that this is due to the encoding. A char is 16 bytes, and some encodings will use one byte for the character, while the other will use two or more. When Java was originally developed, they assumed that any Unicode character would fit in 2 bytes, while now a Unicode character may require up to 4 bytes (UTF-32). There is no way for Scanner represent the UTF-32 code point in one char .

You can specify the Scanner encoding when creating the instance, and if not specified, it will use the platform character set. But this still does not cope with the problem with 3 or 4 byte Unicode characters, since they cannot be represented as a single char primitive (since char only 16 bytes). This way you will get inconsistent results.

Answer 5

To get a specific reason, you need to ask the designer (s) of this API.

But one possible reason is that the (hypothetical) nextChar did not fit very well into the scan model.

• If nextChar() behaved like read() on a Reader and simply returned the next unused character from the scanner, it behaves inconsistently with other next<Type> methods. They skip separator characters before they attempt to parse the value.

• If nextChar() behaves like (say) nextInt , then:

  • skipping the delimiter would be "unexpected" for some people, and

  • the question arises as to whether it should accept a single "raw" character or sequence of digits, which is a numeric representation of char or, perhaps, even supports escaping or something ¹ .

No matter what choice they make, some people would not be happy. I guess the designers decided to stay away from tarpit.

---

^{1 - would vote for the approach associated with the raw symbol ... but the fact is that there are alternatives that need to be analyzed, etc.}