JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)
brent.christian at oracle.com
Thu May 18 18:43:40 UTC 2017
This looks fine to me.
This will get some good bake time in 10, a chance for incompatibilities
(if any) to be revealed.
On 5/17/17 1:54 PM, Brian Burkhalter wrote:
> Please review at your convenience:
> Issue: https://bugs.openjdk.java.net/browse/JDK-8177809 Patch:
> 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
> 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