P3
===
Bad news:
I think I've found a bug in Path.newInputStream() for the default file system. The stream that is returned immediately returns 0 for available(). The javadoc for InputStream woffles a bit but somewhat indicates that 0 means end of file. It seems unreasonable for Path.newInputStream() to return a stream like this. The consequence is that javac immediately thinks the file is empty and stops reading it. If I use FilterInputStream to override the value to always return 1 then javac gets a lot further with this file manager.
-- Jon
===
This is a specific case of:
4648049: (ch) Stream adaptors do not usefully implement available()
Where the channel is to a file (or more generally, a SeekableByteChannel) then it can be special-cased so that the input stream behaves like FileInputStream.
Bad news:
I think I've found a bug in Path.newInputStream() for the default file system. The stream that is returned immediately returns 0 for available(). The javadoc for InputStream woffles a bit but somewhat indicates that 0 means end of file. It seems unreasonable for Path.newInputStream() to return a stream like this. The consequence is that javac immediately thinks the file is empty and stops reading it. If I use FilterInputStream to override the value to always return 1 then javac gets a lot further with this file manager.
-- Jon
===
This is a specific case of:
4648049: (ch) Stream adaptors do not usefully implement available()
Where the channel is to a file (or more generally, a SeekableByteChannel) then it can be special-cased so that the input stream behaves like FileInputStream.
- relates to
-
JDK-4648049 (ch) Stream adaptors do not usefully implement available()
-
- Closed
-