Ricardo,
I see that JDK-8177809[1] has been logged. The newer NIO APIs can report
back with higher time precision and it's probably best to use those.
JDK-6939260 is related to your issue also.
Returning a ms value not equal to the ms value used in the
setLastModified call does seem strange.
regards,
Sean.
[1] https://bugs.openjdk.java.net/browse/JDK-8177809
On 30/03/2017 02:15, David Holmes wrote:
Hi Ricardo,
This isn't a build issue. Redirecting to core-libs-dev. Please don't
reply to build-dev.
Thanks,
David
On 30/03/2017 12:40 AM, Ricardo Almeida wrote:
Hi,
I could not raise a bug in https://bugs.openjdk.java.net/ so I hope it
is ok to say it here, hoping someone can take a look at it...
File.getLastModified() always returns with second precision, losing
the miliseconds (i.e. a number ending in 000). I tried using
Files.getLastModifiedTime and it seems to work correctly as the output
of the following test app shows:
Test f.lastModified [1490606336000]: false
Test Files.getLastModifiedTime [1490606336718]: true
The code:
package com.espatial.test;
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();
}
}
Thanks you,
Regards,
Ricardo Almeida
