Привет всем!

Читал тут 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.