Bug in File.getLastModified() (original) (raw)
David Holmes david.holmes at oracle.com
Thu Mar 30 01:15:09 UTC 2017
- Previous message (by thread): Bug in File.getLastModified()
- Next message (by thread): [10] Request for review and approval: JDK-8177770: Need more precise control on build system logging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Bug in File.getLastModified()
- Next message (by thread): [10] Request for review and approval: JDK-8177770: Need more precise control on build system logging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]