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

[Brian Burkhalter]

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