JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

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

JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian Burkhalter-2
Please review at your convenience.

https://bugs.openjdk.java.net/browse/JDK-6791812

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
      * @return  A <code>long</code> value representing the time the file was
      *          last modified, measured in milliseconds since the epoch
      *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
-     *          file does not exist or if an I/O error occurs
+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative in which case its absolute value indicates the
+     *          number of milliseconds before the epoch
      *
      * @throws  SecurityException
      *          If a security manager exists and its {@link

The weird thing here is that if this method were invoked on a file last modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the file does not exist or whether its last-modified time is the epoch. It seems to me that if the file does not exist it would be better to throw a FileNotFoundException but that is not an issue for JDK 9 at this stage of game.

Thanks,

Brian
Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

roger riggs
Hi Brian,

That looks ok.

The ambiguity (of zero) can't easily be resolved, but I would be inclined,
if the file exists and was created exactly at the epoch to bump the
create time by 1.

Roger


On 5/19/2017 2:59 PM, Brian Burkhalter wrote:

> Please review at your convenience.
>
> https://bugs.openjdk.java.net/browse/JDK-6791812
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -932,7 +932,9 @@
>        * @return  A <code>long</code> value representing the time the file was
>        *          last modified, measured in milliseconds since the epoch
>        *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative in which case its absolute value indicates the
> +     *          number of milliseconds before the epoch
>        *
>        * @throws  SecurityException
>        *          If a security manager exists and its {@link
>
> The weird thing here is that if this method were invoked on a file last modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the file does not exist or whether its last-modified time is the epoch. It seems to me that if the file does not exist it would be better to throw a FileNotFoundException but that is not an issue for JDK 9 at this stage of game.
>
> Thanks,
>
> Brian

Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian Burkhalter-2
Hi Roger,

On May 19, 2017, at 12:08 PM, Roger Riggs <[hidden email]> wrote:

> That looks ok.

Thanks.

> The ambiguity (of zero) can't easily be resolved, but I would be inclined,
> if the file exists and was created exactly at the epoch to bump the create time by 1.

At least that would not be an incompatible change unlike throwing a FileNotFoundException. I doubt a lot of files with the exact epoch timestamp are encountered much at all anyway. In any case either of those solutions would be for JDK 10.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Stuart Marks
In reply to this post by Brian Burkhalter-2
On 5/19/17 11:59 AM, Brian Burkhalter wrote:

> https://bugs.openjdk.java.net/browse/JDK-6791812
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -932,7 +932,9 @@
>       * @return  A <code>long</code> value representing the time the file was
>       *          last modified, measured in milliseconds since the epoch
>       *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative in which case its absolute value indicates the
> +     *          number of milliseconds before the epoch
>       *
>       * @throws  SecurityException
>       *          If a security manager exists and its {@link

This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is
Long.MIN_VALUE, which is still negative. A negative value for "milliseconds
before the epoch" is confusing. It might be sufficient simply to say that
negative values indicate a time prior to the epoch.

This is not outside the realm of possibility. For example, the Mac HFS+ file
system represents time as seconds since January 1, 1904. It seems unlikely :-)
that any Mac files were actually created between 1904 and 1970, but it is a
possibility that somebody could have set a file's timestamp to a date in that range.

> The weird thing here is that if this method were invoked on a file last
> modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
> file does not exist or whether its last-modified time is the epoch. It seems
> to me that if the file does not exist it would be better to throw a
> FileNotFoundException but that is not an issue for JDK 9 at this stage of
> game.

I'll comment on this on the subsequent thread.

s'marks


Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian Burkhalter-2
On May 22, 2017, at 3:52 PM, Stuart Marks <[hidden email]> wrote:

>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -932,7 +932,9 @@
>>      * @return  A <code>long</code> value representing the time the file was
>>      *          last modified, measured in milliseconds since the epoch
>>      *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
>> -     *          file does not exist or if an I/O error occurs
>> +     *          file does not exist or if an I/O error occurs; the value may
>> +     *          be negative in which case its absolute value indicates the
>> +     *          number of milliseconds before the epoch
>>      *
>>      * @throws  SecurityException
>>      *          If a security manager exists and its {@link
>
> This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is Long.MIN_VALUE, which is still negative.

True.

> A negative value for "milliseconds before the epoch" is confusing. It might be sufficient simply to say that negative values indicate a time prior to the epoch.

Or it could say “its mathematically absolute value” which would be accurate.

> This is not outside the realm of possibility. For example, the Mac HFS+ file system represents time as seconds since January 1, 1904. It seems unlikely :-) that any Mac files were actually created between 1904 and 1970, but it is a possibility that somebody could have set a file's timestamp to a date in that range.

Yes, I read about HFS Plus as part of investigating another time issue.

>> The weird thing here is that if this method were invoked on a file last
>> modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
>> file does not exist or whether its last-modified time is the epoch. It seems
>> to me that if the file does not exist it would be better to throw a
>> FileNotFoundException but that is not an issue for JDK 9 at this stage of
>> game.
>
> I'll comment on this on the subsequent thread.

Good!

Thanks,

Brian
Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

roger riggs
Hi Brian,

I don't think you need to mention the absolute value.

+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative indicating the number of milliseconds before the epoch

Roger



On 5/22/2017 6:55 PM, Brian Burkhalter wrote:

> On May 22, 2017, at 3:52 PM, Stuart Marks <[hidden email]> wrote:
>
>>> --- a/src/java.base/share/classes/java/io/File.java
>>> +++ b/src/java.base/share/classes/java/io/File.java
>>> @@ -932,7 +932,9 @@
>>>       * @return  A <code>long</code> value representing the time the file was
>>>       *          last modified, measured in milliseconds since the epoch
>>>       *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
>>> -     *          file does not exist or if an I/O error occurs
>>> +     *          file does not exist or if an I/O error occurs; the value may
>>> +     *          be negative in which case its absolute value indicates the
>>> +     *          number of milliseconds before the epoch
>>>       *
>>>       * @throws  SecurityException
>>>       *          If a security manager exists and its {@link
>> This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is Long.MIN_VALUE, which is still negative.
> True.
>
>> A negative value for "milliseconds before the epoch" is confusing. It might be sufficient simply to say that negative values indicate a time prior to the epoch.
> Or it could say “its mathematically absolute value” which would be accurate.
>
>> This is not outside the realm of possibility. For example, the Mac HFS+ file system represents time as seconds since January 1, 1904. It seems unlikely :-) that any Mac files were actually created between 1904 and 1970, but it is a possibility that somebody could have set a file's timestamp to a date in that range.
> Yes, I read about HFS Plus as part of investigating another time issue.
>
>>> The weird thing here is that if this method were invoked on a file last
>>> modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
>>> file does not exist or whether its last-modified time is the epoch. It seems
>>> to me that if the file does not exist it would be better to throw a
>>> FileNotFoundException but that is not an issue for JDK 9 at this stage of
>>> game.
>> I'll comment on this on the subsequent thread.
> Good!
>
> Thanks,
>
> Brian

Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian Burkhalter-2
Hi Roger,

So I guess this might be satisfy your and Stuart’s comments:

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
     * @return  A <code>long</code> value representing the time the file was
     *          last modified, measured in milliseconds since the epoch
     *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
-     *          file does not exist or if an I/O error occurs
+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative indicating the number of milliseconds before the epoch

Thanks,

Brian

On May 23, 2017, at 7:03 AM, Roger Riggs <[hidden email]> wrote:

> I don't think you need to mention the absolute value.
>
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative indicating the number of milliseconds before the epoch

Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Stuart Marks
On 5/23/17 8:21 AM, Brian Burkhalter wrote:

> So I guess this might be satisfy your and Stuart’s comments:
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -932,7 +932,9 @@
>      * @return  A <code>long</code> value representing the time the file was
>      *          last modified, measured in milliseconds since the epoch
>      *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative indicating the number of milliseconds before the epoch

Yes, this looks great. Thanks.

s'marks

Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian Burkhalter-2
This thread is now moved here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047885.html

Thanks,

Brian

On May 23, 2017, at 1:23 PM, Stuart Marks <[hidden email]> wrote:

> On 5/23/17 8:21 AM, Brian Burkhalter wrote:
>> So I guess this might be satisfy your and Stuart’s comments:
>>
>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -932,7 +932,9 @@
>>     * @return  A <code>long</code> value representing the time the file was
>>     *          last modified, measured in milliseconds since the epoch
>>     *          (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
>> -     *          file does not exist or if an I/O error occurs
>> +     *          file does not exist or if an I/O error occurs; the value may
>> +     *          be negative indicating the number of milliseconds before the epoch
>
> Yes, this looks great. Thanks.
>
> s'marks
>