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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Brian Burkhalter-2
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
Reply | Threaded
Open this post in threaded view
|

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

Brent Christian-2
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
>
Reply | Threaded
Open this post in threaded view
|

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

Brian Burkhalter-2
Hi Brent,

On May 18, 2017, at 11:43 AM, Brent Christian <[hidden email]> wrote:

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

Good point - thanks!

Brian
Reply | Threaded
Open this post in threaded view
|

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

Brian Burkhalter-2
Oh, I guess I need a +1 from a JDK10 Reviewer.

On May 18, 2017, at 12:23 PM, Brian Burkhalter <[hidden email]> wrote:

> Hi Brent,
>
> On May 18, 2017, at 11:43 AM, Brent Christian <[hidden email]> wrote:
>
>> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.
>
> Good point - thanks!
>
> Brian

Reply | Threaded
Open this post in threaded view
|

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

roger riggs
+1

On 5/18/2017 3:34 PM, Brian Burkhalter wrote:

> Oh, I guess I need a +1 from a JDK10 Reviewer.
>
> On May 18, 2017, at 12:23 PM, Brian Burkhalter <[hidden email]> wrote:
>
>> Hi Brent,
>>
>> On May 18, 2017, at 11:43 AM, Brent Christian <[hidden email]> wrote:
>>
>>> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.
>> Good point - thanks!
>>
>> Brian

Reply | Threaded
Open this post in threaded view
|

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

Vyom Tewari
In reply to this post by Brian Burkhalter-2
Hi Brian,

looks good to me, although i am not JDK10 reviewer, one minor comment i
think you can combine the below two statements to one

rv = (jlong)sb.st_mtimespec.tv_sec * 1000;
rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; rv=
(jlong)sb.st_mtimespec.tv_sec * 1000  +(jlong)sb.st_mtimespec.tv_nsec / 1000000;

Thanks,
Vyom


On Friday 19 May 2017 01:04 AM, Brian Burkhalter wrote:

> Oh, I guess I need a +1 from a JDK10 Reviewer.
>
> On May 18, 2017, at 12:23 PM, Brian Burkhalter <[hidden email]> wrote:
>
>> Hi Brent,
>>
>> On May 18, 2017, at 11:43 AM, Brent Christian <[hidden email]> wrote:
>>
>>> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.
>> Good point - thanks!
>>
>> Brian

Reply | Threaded
Open this post in threaded view
|

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

Brian Burkhalter-2
Hi Vyom,

I agree with you but it’s already pushed and I doubt it is worth an issue just to make this small change.

Thanks,

Brian

On May 18, 2017, at 9:05 PM, Vyom Tewari <[hidden email]> wrote:

> looks good to me, although i am not JDK10 reviewer, one minor comment i think you can combine the below two statements to one
>
> rv = (jlong)sb.st_mtimespec.tv_sec * 1000;
> rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; rv= (jlong)sb.st_mtimespec.tv_sec * 1000  +(jlong)sb.st_mtimespec.tv_nsec / 1000000;