Hello Alan,
On 17/03/21 2:45 pm, Alan Bateman wrote:
On 17/03/2021 08:21, Jaikiran Pai wrote:
:
I can confirm that using "NUL" or "nul" work fine in the above code,
I don't know the context for your question
A while back Apache Ant switched to using the
Files.newInputStream/Files.newOutputStream construct as a replacement
for the FileInputStream and FileOutputStream constructors[1]. That
commit seems to have introduced an regression in Ant as noted here[2].
It appears that users of Ant were using "nul" (and even "nul:") as
destination file to have Ant write the data to that destination.
Internally Ant constructs an instance of java.io.File from the user
provided path string ("nul" or "nul:" in this case) and constructs a
OutputStream out of it. Previously (before we made that commit in Ant),
it would be using the FileOutputStream constructor (and would succeed)
and now it uses the Files.newOuputStream(...) which expects a Path
instance and this where our usage of java.io.File.toPath() ran into the
issue I note in this mail, when I started investigating this.
I didn't mention this context in my mail because the error noted in
those user reports is surprisingly a bit different than what I have seen
in my experiments on Windows and I don't think I have so far narrowed it
down to a JDK issue (if any). In their case, it appears the call went
past the issue we are discussing this mail and instead failed later with
something like:
java.nio.file.FileSystemException: E:\nul: Incorrect function.
at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
at
java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
at java.nio.file.Files.newOutputStream(Files.java:216)
I'm not yet sure how they managed to get to that stage and am waiting to
see if they can provide us with a reproducible build file to reproduce this.
but just to mention InputStream.nullInputStream() or
Reader.nullReader() may be useful if you have something that wants to
read from a null stream.
We have had a recent discussion in Ant dev mailing list[3] to introduce
such a construct in some of our Ant tasks where users can tell us that
they want the output/error output discarded (that's what they are using
/dev/null and "nul:" for). That will prevent all these platform specific
usages of null device representations. Internally, in the
implementation, we will use the APIs like the one you note and avoid
having to deal with null devices.
[1]
https://github.com/apache/ant/commit/af74d1f6b882cef5f4167d972638ad886d12d58c
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62330
[3] https://www.mail-archive.com/dev@ant.apache.org/msg48730.html
-Jaikiran
