[
https://issues.apache.org/jira/browse/OAK-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830972#comment-13830972
]
Jukka Zitting commented on OAK-956:
-----------------------------------
For a bit more background on this, Android documentation (that in this case
could be taken as documenting the behavior seen in practice) says the following
about
[available()|http://developer.android.com/reference/java/io/InputStream.html#available%28%29]:
{quote}
Returns an estimated number of bytes that can be read or skipped without
blocking for more input.
Note that this method provides such a weak guarantee that it is not very useful
in practice.
Firstly, the guarantee is "without blocking for more input" rather than
"without blocking": a read may still block waiting for I/O to complete — the
guarantee is merely that it won't have to wait indefinitely for data to be
written. The result of this method should not be used as a license to do I/O on
a thread that shouldn't be blocked.
Secondly, the result is a conservative estimate and may be significantly
smaller than the actual number of bytes available. In particular, an
implementation that always returns 0 would be correct. In general, callers
should only use this method if they'd be satisfied with treating the result as
a boolean yes or no answer to the question "is there definitely data ready?".
{quote}
In practice event assuming such a limited contract is troublesome, as for
example the InflaterInputStream (used to read entries from zip and jar files)
can in some cases return 1 even at the end of the stream (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4795134, resolved "Not an
Issue").
So it would seem that pretty much any interpretation here would be OK from an
implementation perspective, so we could still fall back to returning {{length -
position}} if this is causing more backwards compatibility issues. On the other
hand it's pretty clear that client code like in SLING-3255 is not OK unless it
explicitly makes extra assumptions about the {{InputStream}} implementations it
deals with.
> SegmentStream doesn't implement the method available()
> ------------------------------------------------------
>
> Key: OAK-956
> URL: https://issues.apache.org/jira/browse/OAK-956
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Antonio Sanso
> Priority: Minor
>
> org.apache.jackrabbit.oak.plugins.segment.SegmentStream doesn't implement
> the method available()
> {code}
> Value.getStream().available()
> {code}
> will always return 0
--
This message was sent by Atlassian JIRA
(v6.1#6144)
