RFR 8196298 Add null Reader and Writer

Patrick Reinhart patrick at reini.net
Wed Feb 7 17:38:06 UTC 2018

> Am 07.02.2018 um 14:03 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 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…


More information about the core-libs-dev mailing list