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

Martin Buchholz martinrb at google.com
Mon May 22 20:42:34 UTC 2017

I have no opinion on how to address the problem - just pointing out that
the problem is real.

I might choose an even less likely value than 1 if I were to switch from 0.

(this is not a review!)

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

> So are you suggesting that this would be a bad idea, an incompatible
> change as they would be looking for zero instead of unity?
> On May 22, 2017, at 1:36 PM, Martin Buchholz <martinrb at google.com> wrote:
> > 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).

More information about the core-libs-dev mailing list