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.burkhal...@oracle.com>
wrote:
>
> On May 23, 2017, at 1:34 PM, Stuart Marks <stuart.ma...@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
