Blazkowicz Innate
В этом месте разговор пошел по кругу...

В этом месте разговор можно завершать. Вижу по сути ответить нечего.


Зачем же Вам было повторять то, что было сказано Вами же выше? Получается, что Вам сказать-то
как раз и нечего.

Blazkowicz

Innate
А до конца читать мы не хотим или не умеем, да? См. про isEndOfStream().

Уважаемый, Вы зарываетесь. Побоку что поменять. Требование к available или добавить новый метод. Множество существующих реализаций InputStream станут не совместимыми с этими требованиями. Один из вариантов это ещё придется добавить метод isEndOfStreamDetectionSupported().


Согласен, что проблемы совместимости со старыми версиями остануться в обоих случаях.

Blazkowicz
Вы кажется сами подзабыли о чем спрашивали в исходном топике. Про какие-то эксперименты с Java 6. А какие, к черту, эксперементы, если логика работы класса не менялась?


Не кажется ли вам, что логика работы поменялать. В 1.4.2 и 1.5.0 никто не предлагает использовать available() для определения конца потока, в 6.0 это же это предусматривается, правда как-то неоднозначно. Вот и интересно, как работают хотя бы классы, которые Java API принадлежат.

Blazkowicz


Innate
Здесь я про пример ситуации, в которой принципиально невозможно различить, достигнут ли конец протока или просто доступные для чтения данные закончились. Какое-то физическое устроиство или другой источник данных, доступ к которому абстрогируется с помощью InputStream.
Тю блин. Вот это уже точно разговор ни о чем. Ну допустим у меня есть девайсина с буфером. И я читаю из этого буфера, если там есть данные. Такая себе простецкая реализация. Может там данные уже и никогда не придут. Как мне конец потока определить?
Зачем что-то выдумывать, когда наши с Вами выдумки все равно не охватят нужное множество реализаций?

Не кажется ли Вам, что здесь просто нет конца протока. Метод read() тоже никогда не вернет -1 в этом случае. А вот available() 0 вернуть может.

Kachalov2 Innate
- извините за глупый вопрос, но не могли бы Вы объяснить в каких случаях (для каких задач) Вы планируете использовать метод available()

Да вроде цель, для которой был придуман available(), ясна. Для того, чтобы читать из потока (Stream) данные без блокировки; то есть пока читать нечего, нить (Thread) не блокируется, ожидая прихода данных, а может заняться чем-то другим, прериодически проверяя, с помощью метода available(), не проявилось ли что-то для чтения.

mayton2 Innate

За определённые деньги я напишу для вас одну из реализаций InputStream для чтения потока файла с возможностью "смотреть вперёд". Вопросы согласованности/конкуренции/версионности буду игнорировать, как не имеющие значения для постановки.

Вас это устроит?

Да мне пока не надо. Но буду иметь вас в виду. :)

Blazkowicz InnateНе кажется ли вам, что логика работы поменялать.
Нет не кажется.
InnateВ 1.4.2 и 1.5.0 никто не предлагает использовать available() для определения конца потока, в 6.0 это же это предусматривается, правда как-то неоднозначно.
Как раньше так и сейчас никто не предлагал использовать available для определения конца потока.
Как раньше так и сейчас available() возвращает 0 в обоих случаях - конец потока и не возможность чтения без блокировки.

InnateВот и интересно, как работают хотя бы классы, которые Java API принадлежат.
Как работали так и работают. Буфер пустой? available==0. Конец данных? available==0.

Предлагаю сойтись на почти полной бесполезности метода available.

Ок. Сошлись. :)

Kachalov Blazkowicz
Показательный пример это задача чтения из большого количества потоков, данные на которые поступают крайне медленно. Для всех этих потоков имеет смысл завести ограниченое число нитей, которые будут их перебирать и вычитывать данные.
- все равно нужна дополнительная "контрольная" нить, "которая будет их перебирать", т. е. что бы ни говорил Innate о пользе метода available, а задачу надо решать путем создания многопочного приложения (с "контрольной нитью" или без нее это уже детали зависящие от планируемой нагрузки). А многопоточное приложение работающее с потоками данных это классика программирования на Java, такой пример разбирается в каждой книжке по Java :)

Все это верно. Только с блокировками придется создавать отдельную нить для чтения каждого потока, чтобы обрабатывать данные как можно раньше после их появления в потоке, что при большом количестве потоков не является хорошей идеей.