Это действительно любопытство больше, чем проблема...
Почему класс Scanner не имеет метода nextChar()? Похоже, это должно произойти, если учесть, что он имеет next, nextInt, nextLine и т.д. Метод.
Я понимаю, вы можете просто сделать следующее:
userChar = in.next().charAt(0);
System.out.println( userChar );
Но почему бы не использовать метод nextChar()?
Причина в том, что класс Scanner предназначен для чтения в токенах, разделенных пробелами. Это класс удобства, который обертывает базовый поток ввода. Перед сканером все, что вы могли сделать, было прочитано в байтах, и это большая боль, если вы хотите читать слова или строки. С помощью Scanner вы передаете System.in и выполняет ряд операций read() для токенизации ввода для вас. Чтение одного символа - более простая операция. Источник
Вы можете использовать (char) System.in.read();.
В соответствии с javadoc a Scanner, похоже, не предназначен для чтения одиночных символов. Вы прикрепляете Scanner к InputStream (или что-то еще), и он анализирует ввод для вас. Он также может вырезать нежелательные символы. Таким образом, вы можете легко читать числа, строки и т.д. Если вам нужны только символы с вашего ввода, используйте InputStreamReader, например.
Класс Scanner - это основы для логики, реализованной в методе String next(Pattern). Дополнительный API-метод, например nextDouble() или nextFloat(). Предоставьте шаблон внутри.
Затем класс описание говорит:
Простой текстовый сканер, который может анализировать примитивные типы и строки используя регулярные выражения.
Сканер разбивает свой вход на токены, используя шаблон разделителя, который по умолчанию соответствует пробелу. В результате токены могут быть преобразуются в значения разных типов, используя различные следующие Методы.
Из описания может быть грустно, что кто-то забыл о char, поскольку он является примитивным типом.
Но понятие класса состоит в том, чтобы находить шаблоны, char не имеет шаблона, это просто следующий символ. И эта логика ИМХО вызвала то, что nextChar не был реализован.
Если вам нужно прочитать файл char на char, вы можете использовать более эффективный класс.
Я бы предположил, что это связано с кодировкой. A char - 16 байт, а некоторые кодировки будут использовать один байт для символа, тогда как другой будет использовать два или даже больше. Когда Java была изначально разработана, они предположили, что любой символ Юникода будет вписываться в 2 байта, тогда как теперь для символа Unicode может потребоваться до 4 байтов (UTF-32). Нет способа, чтобы Scanner представлял кодовую точку UTF-32 в одном char.
Вы можете указать кодировку Scanner при создании экземпляра, а если не указывать, то он будет использовать набор символов платформы. Но это все еще не справляется с проблемой с 3 или 4 байтовыми символами Unicode, поскольку они не могут быть представлены как один примитив char (так как char всего 16 байт). Таким образом, вы получите непоследовательные результаты.
Чтобы получить определенную причину, вам нужно спросить дизайнера (ов) этого API.
Но одна из возможных причин состоит в том, что намерение (гипотетическое) nextChar не очень хорошо вписывалось в модель сканирования.
Если nextChar() вел себя как read() на a Reader и просто возвращал следующий неиспользуемый символ из сканера, он ведет себя непоследовательно с другими методами next<Type>. Они пропускают символы разделителя, прежде чем они попытаются проанализировать значение.
Если nextChar() вести себя как (скажем) nextInt, то:
пропущение разделителя было бы "неожиданным" для некоторых людей, а
возникает вопрос о том, должен ли он принимать один "сырой" символ или последовательность цифр, которая является числовым представлением char или, возможно, даже поддерживает экранирование или что-то 1.
Независимо от того, какой выбор они сделали, некоторые люди не были бы счастливы. Я предполагаю, что дизайнеры решили держаться подальше от tarpit.
1 - проголосовал бы за подход, связанный с сырым символом... но дело в том, что есть альтернативы, которые необходимо проанализировать и т.д.