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

[Brent Christian]

Hi, Brian

This looks fine to me.

This will get some good bake time in 10, a chance for incompatibilities 
(if any) to be revealed.

-Brent

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:
> 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.
>
> Thanks,
>
> Brian
>