On 22/03/21 2:36 pm, Alan Bateman wrote:
On 20/03/2021 07:16, Jaikiran Pai wrote:
:
I received some inputs on that Ant bugzilla issue. Based on that, I
was able to reproduce the exception and IMO it's a bug in
Files.newOutputStream() API. I have opened
https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant
details. I considered this a bug and took the liberty of opening that
JBS issue because as I note in that issue, this only happens
specifically when TRUNCATE_EXISTING (default) option gets used
against "nul" on Windows.
OutputStream.nullOutputStream() may be a better and more portable
alternative. In general, the DOS era reserved names (including NUL)
are very under specified and many file operations lead to surprising
behavior (this isn't solely a JDK issue, I think other runtimes and
languages also get tripped up). In this case, the attempt to truncate
the file to zero length is failing. Sure, it can be be worked around
but workarounds like this tend to cause issues in other unusual cases
so care is required.
Understood. Thank you Alan for those inputs. Just yesterday, Stefan (one
of the Ant developers) has implemented a way where we allow users to
discard output without relying on null devices. It uses the approach
that you note (although we use an internal NullOutputStream, since we
want Ant to be usable in Java 8 where OutputStream.nullOutputStream()
isn't present). We will be asking our users to move to this new
way/attribute instead of relying on null devices.
-Jaikiran
