FULL PRODUCT VERSION :
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b14)
OpenJDK 64-Bit Server VM (build 25.121-b14, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux ess-hwvj 4.10.5-200.fc25.x86_64 #1 SMP Wed Mar 22 20:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
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.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create and run the following the FileTest class added to the source-code for test case


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Test f.lastModified [1490606336718]: true
Test Files.getLastModifiedTime [1490606336718]: true

ACTUAL -
Test f.lastModified [1490606336000]: false
Test Files.getLastModifiedTime [1490606336718]: true


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;

public class FileTest {
    private static final long LM = 1490606336718L;

    public static void main(String[] args) throws IOException {
        File f = new File("test.txt");
        f.createNewFile();

        f.setLastModified(LM);

        System.out.printf("Test f.lastModified [%s]: %b\n",
f.lastModified(), f.lastModified() == LM);
        System.out.printf("Test Files.getLastModifiedTime [%s]: %b\n",
Files.getLastModifiedTime(f.toPath()).toMillis(),
(Files.getLastModifiedTime(f.toPath()).toMillis() == LM));

        f.delete();
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Call Files.getLastModifiedTime(f.toPath()).toMillis() instead of f.lastModified()