JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

Brian Burkhalter brian.burkhalter at oracle.com
Tue May 23 15:03:17 UTC 2017


Or perhaps per Alan’s comments below change the current wording

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.

to

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, or Files.getLastModifiedTime() if only this timestamp is needed.

?

I think it’s come down to either this just resolve it without change.

Brian

On May 23, 2017, at 7:07 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> +1
> 
> Roger
> 
> On 5/22/2017 7:20 PM, Brian Burkhalter wrote:
>> 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
> 

On May 23, 2017, at 3:02 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 23/05/2017 00:15, Stuart Marks wrote:
> 
>> 
>> I think this is sufficient. People who care about this case will have to rewrite their code using Files.readAttributes instead of File.lastModified.
> or Files.getLastModifiedTime if only this timestamp is needed.




More information about the core-libs-dev mailing list