JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)

Brian Burkhalter brian.burkhalter at oracle.com
Wed May 17 20:54:44 UTC 2017

Please review at your convenience:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8177809
Patch:	http://cr.openjdk.java.net/~bpb/8177809/webrev.00/

Change the native portion of the Unix implementation to use the full time structure available. Note that for macOS, at least with HFS Plus, this will not increase the accuracy as in that case dates are stored in unsigned 32-bit integers containing the number of seconds since midnight, January 1, 1904, GMT, therefore millisecond granularity is unavailable on that platform.

To verify the results, regression test jobs without the patch were run against JDK 9 and with the patch against JDK 10. These tests verified that the change affects the value returned by File.lastModified() for linux_i586, linux_x64, solaris_sparcv9, and solaris_x64 making them be the same as that returned for windows_i586 and windows_x64. The value returned on macOS is unchanged (running HFS+).

One arguable objection to making this change is that it might be incompatible as some applications could depend on the value's being less accurate.



More information about the core-libs-dev mailing list