JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous
Brian Burkhalter
brian.burkhalter at oracle.com
Mon May 22 23:20:30 UTC 2017
On May 22, 2017, at 4:15 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> So yes, I'd say that returning 1L (or any other value) instead of 0L would be an incompatible change.
I think the correct solution would be to throw a FNFE for a non-extant file but that is also incompatible.
> The specification for File.lastModified already has this note:
>
>> Where it is required to distinguish an I/O exception from the case where 0L
>> is returned, or where several attributes of the same file are required at the
>> same time, or where the time of last access or the creation time are
>> required, then the Files.readAttributes method may be used.
>
> I think this is sufficient. People who care about this case will have to rewrite their code using Files.readAttributes instead of File.lastModified.
On reflection, so to speak, I think I have to agree with you. I’ll leave the issue open for the time being but unless a compelling alternative solution arises should probably resolve it as “Won’t Fix.”
Thanks for the careful commentary.
Brian
More information about the core-libs-dev
mailing list