JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000)

[Ismael Juma]

Hi all,

The following was stated in JDK-8177809:

"File.getLastModified() always returns with second precision, loosing the
milliseconds (i.e. a number ending in 000). I tried using
Files.getLastModifiedTime and it seems to work correctly."

It doesn't look like Files.getLastModifiedTime works correctly either (at
least in some cases). I tested Java 10 on macOS High Sierra and APFS and
File.getLastModified has better behaviour now:

~ ❯❯❯ java --version
java 10-ea
Java(TM) SE Runtime Environment (build 10-ea+30)
Java HotSpot(TM) 64-Bit Server VM (build 10-ea+30, mixed mode)

jshell> import java.io.File

jshell> import java.nio.file.Files

jshell> File f = new File("Downloads")
f ==> Downloads

jshell> Files.getLastModifiedTime(f.toPath()).toMillis()
$8 ==> 1512376609000

jshell> f.lastModified()
$9 ==> 1512376609808

In the following SBT (Scala build tool) issue, someone tested on Ubuntu
16.04 and Files.getLastModifiedTime had 000 for the milliseconds part while
a JNA-based library did not:

println(getModifiedTime(filePath))   // native
1512178359814

println(Files.getLastModifiedTime((new File(filePath)).toPath).toMillis)
1512178359000

https://github.com/sbt/io/pull/92#issuecomment-348657222

Since I'm not able to post in the JIRA ticket, I thought I'd report the
issue here. It would be unfortunate for File.getLastModified to have better
behaviour than Files.getLastModifiedTime in Java 10.

Ismael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171204/52e75177/attachment.html>