Comments 17
Чем-то похоже на статью "SQL vs. CSS What’s the Difference? Which Is Better?". Почему именно и только эти два ридера выбраны для сравнения?
Что лучше String или Spring, или Swing ?
Прошу прощения, если вопрос дурацкий - но ведь статья вроде бы рассчитана на новичков? Вот я как раз такой новичок и есть: язык не использую, но крокодил мимо, и заглянул, чтобы узнать ответ на вопрос: в каких случаях FileReader предпочтительнее, чем BufferedReader? Было интересно узнать, как это устроено
у соседей
у меня в языке тоже можно эмулировать аналогичные конструкции, и там я знаю одно преимущество: если мне лень заранее проверить длину файла (или это не файл), то FileReader сообщит про конец файла с точностью до символа, а при использовании BufferedReader мне это придется выяснять самому
Увы, но из статьи я смог лишь понять, что BufferedReader всегда лучше. А зачем тогда FileReader ?
BufferedReader читает из потока, у него нет метода чтения из файла, для того, чтобы читать из файла ему нужен FilerReader или FileInputStream. Если проваливаться дальше, то в данных примерах нет особого выигрыша в перфомансе, так как все упирается в один метод чтения.
Захват файла. Читаем один байт. Отпускаем файл. Добавляем в оперативку.
Захват файла. Читаем н байт до конца строки по одному из файла. Отпускаем файл. Добавляем н байт в оперативку. Работаем с массивом байтом из оперативки: добавляем в другой массив.
метод чтения в первом и втором случае одинаковый. И он native, то есть написан не на Java.
Потому что статья дурацкая. А ваш вопрос нормальный. Во-первых, интерфейс Reader (а остальные упомянутые классы его реализуют), это интерфейс для чтения из любых потоков символов. То есть, они работают с char[], и понимают, что такое кодировка, и сколько байтов нужно считать с диска, чтобы получить один символ UTF-16, к примеру.
Direct Known Subclasses:
BufferedReader, CharArrayReader, FilterReader, InputStreamReader, PipedReader, StringReader
Заметьте, что тут нет FileReader (потому что он скорее всего не реализует Reader непосредственно, а является наследником InputStreamReader с FileInputStream в качестве входа).
Вот кто судя по документации реализует Reader. Как можно догадаться, они умеют читать из CharArray, String, InputStream, а еще есть некие специальные Filter и Piped, которые делают сразу непонятно что. А еще есть PushBackReader, который может запихнуть символы обратно в поток. И понятно что много чего еще.
Ну и BufferedReader, про который как раз речь.
Ну так вот, BufferedReader вовсе не "лучше". Он просто применяется к другому ридеру, и буферизует поток данных, чтобы дело шло быстрее. То есть это буфер. Поверх другого ридера. В общем случае любого. Который сам по себе бесполезен.
@sshikovспасибо! Ваш комментарий для меня оказался полезней статьи. Впрочем, на Хабре это часто бывает ;-)
Да не за что. Совет — научитесь и не ленитесь читать код классов, который либо доступен, либо легко декомпилируется скажем IDEA, либо Javadoc. Они конечно не идеальны, но разницу между классами таки можно понять. Во-первых, они зачастую понятнее документации, а во-вторых, они как правило не врут (код уж точно).
@adeshere еще лучше не ленитесь читать книги по сертификации Java, там все это подробно расписано, ответы на свои вопросы вы там точно найдете. Конкретно эта тема освещается в OCP-ll.
@IceWanderer, Ваш совет мудрый, но к сожалению, у меня немного другая специфика. Дело в том, что я не планирую изучать Java или писать на нем, и заглянул сюда только за идеями, а не за конкретикой
А для знакомства именно с идеями книги по сертификации - это не самый идеальный инструмент...
Вообще, у меня совсем другая специальность, а программированием я занимаюсь попутно для работы с геофизическими рядами данных. Тем не менее, когда-то в очень далеком DOS-овском прошлом я написал свои аналоги обсуждаемых функций, так как встроенная в мой язык буферизация тогда работала с очень большими ограничениями. И с тех пор это legacy является основой большинства моих функций доступа к файлам с данными и конфигам (разумеется, развиваясь и допиливаясь под новые задачи). Поэтому я заглянул в эту тему, чтобы присмотреть что-то полезное для себя с точки зрения идей: какие еще фичи потенциально могут быть полезными в моей ситуации, не нужно ли мне что-то еще в свой фреймворк прикрутить? Обычно статьи на Хабре как раз и позволяют за пару минут ухватить суть вопроса. И уже после этого, в зависимости от результатов, либо сразу бежать кодировать, либо разочарованно утопиться. Ну или сесть и заняться раскуриванием доков. А просто так, без наводки, перечитать все доки по всем языкам - никакой жизни не хватит. Ведь для меня читать доки и вообще самообразовываться - это
скорее удовольствие, чем работа
Напрямую (в ближайшей перспективе) это никак на мою результативность не влияет. И в будущем если и повлияет, то только косвенно (я уже давно на одно месте работаю, и вроде как себя там нашел, поэтому крайне маловероятно, что в программеры когда-то уйду).
Поэтому я на Хабр заглядываю больше для отдыха и расширения кругозора, чем по необходимости. И вот с этой точки зрения чтение хороших статей (и комментов к ним) гораздо полезнее (да и приятнее), чем чтение доков
Никогда не понимал, зачем нужны такие сертификаты. На практике нормально использовать скажем процентов 20 возможностей языка.
Я не хочу сказать, что сертификаты не нужны никому. Возможно, есть такая работа, где подобный сертификат реально пригодится, но как по мне — о ваших умениях программировать он говорит довольно мало. И на интервью, скажем у меня, скорее вызывает мысли типа: "А, тут кто-то претендует на звание гуру, дай-ка мы зададим ему вопросы посложнее". А оно вам надо, посложнее? :)
Впрочем, у вас написано не "получите сертификат", а "прочитайте книги", и в такой постановке я согласен. В конце концов, прочитать спецификацию языка — тоже хоть и очень муторно, потому что она большая и местами сложная, но в целом полезно.
Уже месяца 2 радовался, что подобные КДПВ исчезли с хабра.
Их какая то программа генерит? Я без шуток и наездов — правда не понимаю откуда они берутся.
Есть ещё одна категория — какие то толстые люди, плавающие в воздухе.
Это хуже, чем у вас.
Несколько натянутый пример про побайтовое чтение. Редко когда читают посимвольно. Скорее массив символов.
Кроме того, как же кэш диска? Данные ситаются не байтами а секторами.
Кэш дисковых операций в операционной системе?
В примере с текстом в килобайты что один ридер что другой будут читать из памяти.
Так же вопрос со стороны новичка, почему используется конструкция
while((line = br.readLine()) != null)
, а не
while(br.ready())
Просто что бы сократить код и не писать в цикле br.readLine() ?
Разница между FileReader и BufferedReader в Java