Привет всем!

Читал тут JavaDoc API. Наткнулся на то, что описание InputStream.available() различается для разных версий Java. Особенно обратите внимание на Returns.

http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html#available()

Returns:
the number of bytes that can be read from this input stream without blocking.

http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#available()

Returns:
the number of bytes that can be read from this input stream without blocking.

http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available()

Returns:
an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking or 0 when it reaches the end of the input stream.

Обычно этот метод использует для того, чтобы считывать данные из потока (Stream), не блокируя при этом нить (Thread, тоже поток, конечно, но я использовал термин нить для Thread, чтобы не было путаницы).

Рассмотрим версии 1.4.2 и 1.5.0. Вроде все не плохо. Узнаем, сколько байт можно считать из потока без блокировки, и считываем их. Проблемы начинаются, когда надо определить, что поток закончился. available() может вернуть 0, что говорит о том, что доступных данных нет, но данные могут стать доступны позже. И единственный способ определить то, что достигнут конец потока, это вызов метода read() и проверка возвращенного значения. Если достигнут конец потока, получим -1, иначе метод блокируется, если данные еще не доступны. Это верно для версий 1.4.2 и 1.5.0. Итак, гарантированно избежать блокировки и определять конец потока не получается. Из всего описания класса InputStream следует, что конец потока достигается тогда, когда в нем нет больше доступных данных и никогда больше не будет доступных данных. (Комментарии приветствуются.)

Посмотрим теперь на версию 6.0. Во-первых, напрягает слово "estimate". Нигде это не сказано, и можно только надеяться, что это оценка снизу, то есть по меньшей мере из потока можно считать такое число байт, какое вернул available(), но, может быть, в потоке доступно и больше. Также из описания следует, что available() возвращает 0, когда достигнут конец потока. Из этого можно заключить, что, возможно, изменилось определение понятия "конец потока". Я рассмотрю два варианта, один из предыдущего параграфа, другой новый.
(1) конец потока достигается тогда, когда в нем нет больше доступных данных и никогда больше не будет доступных данных.
(2) конец потока достигается тогда, когда в нем нет больше доступных данных, но, если данные появятся, конец потока будет сдвинут, и эти данные можно будет считать.

Предположи верно определение (1). Тогда, если метод available() вернул 0, мы больше никогда ничего считать из потока не сможем. С другой стороны, если конец потока не достигнут, то available() не должен возвращать 0, и предпологая, что этот метод не может возвращать отрицательные заначения, он вернет положительное число. Это приводит к выводу, что в потоке, конец которого не достигнут всегда есть доступные данные, и чтение может проходить без блокировки, что трудно себе представить, например, при медленном соединении по сети.

Предположи верно определение (2). Вообще говоря, этот вариант приводит к тем же проблемам, что в версиях 1.4.2 и 1.5.0, только прибавляется еще одна. Если предположить, что понятие конец потока общее для методов available() и read(), что естественно, то метод read() не гарантирует, что данных для чтения больше не будет.

Мне интересно ваше мнение по этому поводу. Проводил ли кто-нибудь эксперименты, всегда ли доступны данные для чтения в версии 6.0? Может это просто опечатка, и метод available() возвращает -1 по достижении конца потока? Не кажется ли вам, что, если бы available() возвращал -1 по достижении конца потока, это было бы удобнее? Если нельзя менять метод available() из-за обратной совместимости, то можно добавить isEndOfStrean(), который возвращает boolean?

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

Спасибо, Timm, за ссылку. Итак, то, что я описал для версий 1.4.2, 1.5.0 в 6.0 постарались исправить. Только, по-моему, не лучшем образом.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4401029

Blazkowicz InnateInputStream, для начала, - это не интерфейс, а абстракный класс.
Ооо, это многое меняет.


Для Java это многое меняет.

Blazkowicz
Может посмотрим как в этом абстрактном классе реализован метод available()?
Сюрприз!


Нет, не сюрприз! По-моему там прямо сказано, что, хоть метод и реализован, его необходимо переопределить в наследнике. Так что, как метод available() реализован в самом InputStream не столь важно. А важен его контракт и предпологаемое его поведение.

Blazkowicz
InnateВозможно, у него есть и сотня реализаций, я не считал.
Конечно, это ведь не важно. Метод available всегда возвращает 0, как видно из исходного кода абстрактного класса InputStream.


Ну это просто уже смешно! :) Конечно, метод available() может вернуть и что-то другое, если его переопределить в наследнике класса InputStream.

Blazkowicz
InnateТолько я не вижу причин, почему сделано послабление, которое приводит к противоречию.
Ну, другие видят, раз формулировку сменили.


Видите ли их Вы? Если да, не могли бы поделиться?

Blazkowicz
InnateКакой источник данных вы можите предложить, Blazkowicz, который бы соответствовал тому, что написано в документации, но противоречил бы более строгому описанию.
Смотри Related Bugs. Спасибо Timm за оперативный поиск.

InnateДа, кстати в Release Notes я не нашел ничего про InputStream. Может дадите ссылку?
https://jdk6.dev.java.net/files/documents/5490/39025/jdk6-b45.html

Пока я нашел только баги, которые привели от спецификации версий 1.4.2 и 1.5.0 к спецификации версии 6.0. Так что проблема остается.

Timm Innate
Пока я нашел только баги, которые привели от спецификации версий 1.4.2 и 1.5.0 к спецификации версии 6.0. Так что проблема остается.
(слишком многа букв в первом посте)
Какая проблема?
конец потока == available() = 0.

Да. А в остальных случаях, что вернет available()? Наверное, не отрицательное число, а положительное. Вот и получается, что пока не достигнут конец потока, из него всегда можно считать по крайней мере один байт без блокировки, что не всегда правда.

Blazkowicz InnateДля Java это многое меняет.
Нет, не сюрприз! По-моему там прямо сказано, что, хоть метод и реализован, его необходимо переопределить в наследнике. Так что, как метод available() реализован в самом InputStream не столь важно. А важен его контракт и предпологаемое его поведение.
Ну это просто уже смешно! :) Конечно, метод available() может вернуть и что-то другое, если его переопределить в наследнике класса InputStream.

Ага. Судя по всему таки появилось понимание того что нельзя говорить об InputStream в отрыве от множества реализаций. Или нет?
Хотите Вы того или нет, но когда у Вас есть только ссылка типа InputStream, и Вы не знаете, объект какога типа она адресует в действительности, Вам ничего другого и не остается, кроме как говорить о InputStream, а не о его реализации.

Timm
Нет тут противоречия. Скорее всего имплементации available() таковы, что при вызове Available() поток будет блокирован до того момента как появится что то для чтения. последующий вызов read вычитает то что сможет, уже без блокирования.
т.е. да, available() всегда будет возвращать >=0 значение.
я так думаю.

Может и так, но ничего подобного в описании InputStream нет. Такая реализация available() практически безполезна. Пока приходится работать с тем, что есть...

Blazkowicz
Это не верное заключение. 0 возвращается в обоих случаях если конец файла и если нет данных для чтения без блокировки.

Что возвращает нас к проблеме, описанной в первом посте. В любом случае, такое неоднозначное поведение совершенно неприемлемо.

Blazkowicz
Хотите Вы того или нет всегда существует множество реализаций InputStream поведение которых влияет на документацию InputStream. Потому как создание слишком жестких рамок в спецификации InputStream вызовет проблемы с реализацией для некоторых протоколов. Посему спеуификация и послабляется, дабы дать шанс всем.


Вот мне и интерестно, если ли реализации (или, скорее, примеры ситуаций), которые не допускают того, чтобы available() возвращал -1 по достижении конца потока, или нельзя было бы добавить isEndOfStrean(). Я пока не могу себе такое представить.

Blazkowicz
Ну, другие видят, раз формулировку сменили.


Может все-таки приведете пример ситуации, раз утверждаете это.

Blazkowicz Innate Blazkowicz
Это не верное заключение. 0 возвращается в обоих случаях если конец файла и если нет данных для чтения без блокировки.

Что возвращает нас к проблеме, описанной в первом посте. В любом случае, такое неоднозначное поведение совершенно неприемлемо.

Может быть оно и не приемлимо. Но сути это не меняет. Поменялась только документация! Она объясняет что 0 может вернуться не только когда не возможно чтение без блокировки, но и когда все данные из потока были вычитаны.


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

Blazkowicz


Innate
Вот мне и интерестно, если ли реализации (или, скорее, примеры ситуаций), которые не допускают того, чтобы available() возвращал -1 по достижении конца потока, или нельзя было бы добавить isEndOfStream(). Я пока не могу себе такое представить.

Тут уже вопрос не в реализациях а в обратной совместимости. Если обязать InputStream.available()возвращать отрицательное значение, то сразу множество реализаций, о которых я пишу не первый раз, станут не валидными.



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

Blazkowicz

InnateМожет все-таки приведете пример ситуации, раз утверждаете это.
Мы тут про estimate или про конец файла?

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

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 :)

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