Because we cannot change the behaviour of File constructorsto error out
the bad input immediately, the changes will be scattered all over many
java io methods, especially methods in File.java, if we choose to reject
bad inputs. And due to the delay of the rejection, it also brings a
little headache to developers to find out why the exception
happens.Comparing with that, the proposed approach is simple and resilient.
In addition, the currentnormalization logic already tolerates some
invalid path-name formats and invalid characters. This approach can be
regarded as a extension of the tolerance to theNUL character. It is
consistent with what the native platform would do with a null and
what/how we are currently normalizing the "slash".Thanks!
-Dan
On 02/27/2013 10:31 AM, Mike Duigou wrote:
Ouch. That is unfortunate that File cannot reject bad input.
Perhaps FileInputStream etc. should throw a specialized "Bad Filename" FnF for
paths containing NUL if the underlying filesystem does not support NUL?
Masking garbage input always really scares me.
Mike
On Feb 27 2013, at 02:40 , Alan Bateman wrote:
On 27/02/2013 02:31, Dan Xu wrote:
Thank you, Mike.
The reason not to throw out an exception is for the backward compatibility. Due
to that, the constructorof File object with NUL willnever fail.While in NIO, it
is defined in the spec to throw out exceptions when invalid NUL character is
found.
-Dan
Right, we can't change the constructor to throw an exception, particularly if
this fix is going to be back-ported to 7u. For NIO then it's not an issue
because getPath was specified from the begining to throw the unexpected
InvalidPathException when it is given garbage.
-Alan.
