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

[Martin Buchholz]

I have seen such filesystems in the wild.  Imagine that a virtual
filesystem has to make up metadata for an object not actually stored, e.g.
a directory for a file system backed by a source code control system that
does not have directory artifacts.  Filesystem authors are likely to pick
the value 0 for timestamps, even though that is likely to cause trouble
(later than 2000 is much safer).

On Mon, May 22, 2017 at 1:22 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8180767
> http://cr.openjdk.java.net/~bpb/8180767/webrev.00/
>
> java.io.File#lastModified() returns zero if the file in question does not
> exist. If however the file does exist and by some fantastic improbability
> has a last-modified time equal to the epoch, then a caller literally
> following the specification verbiage would interpret the returned value of
> zero as signifying that the file does not exist. It would probably be ideal
> to throw a FileNotFoundException when the file does not exist, but instead
> here we propose to return unity (1) instead of zero when the last-modified
> time of the file equals the epoch.
>
> Note that this webrev is with respect to the one for [1] which is
> currently pending CCC approval, and is shown in the webrev in the JDK 9
> tree. As it contains code changes, it would however be pushed to JDK 10
> after the patch for [1] has been pushed and eventually migrated into the
> JDK 10 repository.
>
> Thanks,
>
> Brian
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-
> May/047787.html