JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

[Brian Burkhalter]

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 2:27 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> 
> On May 23, 2017, at 1:34 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
>> Yes, this could be another non-normative change. You might even consider merging it with the other bug (JDK-6791812), and possibly even labeling it as @apiNote.
>> 
>> As for the wording itself, I think the sentiment is correct, but it's trying to pack a bit too much into a single sentence. Breaking it into two sentences would probably be helpful.
> 
> Does this seem better? It folds 8180767 into 6791812.
> 
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -928,11 +928,17 @@
>      * the granularity of the value depends on the underlying
>      * file system and may be larger.  For example, some
>      * file systems use time stamps in units of seconds.
> +     * Distinguishing an I/O exception from a zero return value may
> +     * also be accomplished by using the
> +     * {@link java.nio.file.Files#getLastModifiedTime(Path,LinkOption[])
> +     * Files.getLastModifiedTime} method.
>      *
>      * @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
> 
> I already verified that the generated javadoc is correct.
> 
> Thanks,
> 
> Brian