> Am 07.02.2018 um 14:03 schrieb Alan Bateman <[email protected]>:
>
> On 03/02/2018 17:05, Patrick Reinhart wrote:
>> :
>> I reworked the tests and Writer implementation accordingly
>>
>> http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01
>>
> Just catching up on this.
>
> nullReader’s javadoc suggests that mark(int) does not nothing but this seems
> to conflict with the Reader's javadoc where it is specified to throw IOE when
> mark is not supported.
So I will change the API description accordingly there…
>
> I'm a bit uneasy with len==0 check in the read method. I realize this is
> trying to mirror InputStream.read and maybe some Reader implementations but
> it's not specified behavior. I think we have to re-examine the Reader spec to
> clarify this to avoid creating more inconsistencies.
That’s exactly what I did, so for me it’s ok to look into the Reader spec also
as I already modify that File. I personally thought that a null like reader
will always be at the end of the stream and therefore return -1 and do no
checking of how much space may be left on the consuming end. That seem to me
more the natural way of thinking.
>
> Similarly in nullWriter() where it looks like the the len==0 checks is in
> unspecified territory. I think this will need clarifications to the Writer
> spec. One obvious inconsistency is to close the writer and call write("") and
> write("", 0, 0). The first will fail as the writer is closed, the second
> does not fail.
Here I think the same holds true as I wrote for the Reader…
>
> Another one is read(CharBuffer). Suppose CharBuffer cb has 0 bytes remaining;
> if I invoke nullReader().read(cb) then it looks like it will return 0 whereas
> the read(CharBuffer) method is specified to return -1.
>
I see your point there, the implementation I did there was taken from the
StringReader, where it will be the same len==0 check as you mentioned before…
So it looks like we really need to look into those implementations…
-Patrick
