Hi everyone responded so far. How should we proceed now?
-Patrick Am 07.02.2018 um 18:38 schrieb Patrick Reinhart: >> Am 07.02.2018 um 14:03 schrieb Alan Bateman <alan.bate...@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… > > -Patrick > >
