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