Pull to refresh

Comments 8

Категорически не согласен с тем, что Вы внутри copy закрываете стримы. В общем случае правило должно звучать так:
1. открыл — закрой
2. не я открыл — не мне закрывать

В этом частном случае закрытие InputStream еще, скорее всего, будет безопасно, ибо вряд ли кому-то он еще нужен, после того, как закончились данные. Но вот закрытием OutputStream Вы делаете абсолютно невозможным использование библиотеки.
Согласен с Вами.
Скорее просто хотелось продемонстрировать try-with-resources (это таки лабораторная, а не библиотека).
Это как раз тот случай, когда удобно использовать лямбды. Метод copy() мог бы выглядеть как-то так:
public static void copy(Supplier<InputStream> getSrc, Supplier<OutputStream> getDst) throws IOException {
    try (InputStream src = getSrc.get(); OutputStream dst = getDst.get()) {
        ...
    }
}

Кстати, в коде тесте у вас ошибка: У класса ByteArrayOutputStream нет конструктора без параметров. Так что он даже не скомпилируется.
Пардон, перепутал с ByteArrayInputStream. В ByteArrayOutputStream действительно можно параметр не передавать.
У вас на сайте пустая глава «Что Вы будете знать по окончанию курса» — несколько сбивает мотивацию ИМХО
В последнем двупоточном решении читатель постоянно создает новые byte[]-буфера, передает их писателю, а тот отправляет на съедение GC. Создайте отдельную обратную очередь пустых буферов от писателя к читателю.

Вы имеете ввиду, что в писателе на переменную byte[] data перестают ссылаться и она удаляется GС, так ведь? Но не вполне понял, почему «очередь пустых буферов», ведь после записи в output поток byte[] data ведь не стал пустым?
С точки зрения «полезных»/новых/неизвестных данных — он пустой.
Sign up to leave a comment.