Hi Brian,
That looks ok.
The ambiguity (of zero) can't easily be resolved, but I would be inclined,
if the file exists and was created exactly at the epoch to bump the
create time by 1.
Roger
On 5/19/2017 2:59 PM, Brian Burkhalter wrote:
Please review at your convenience.
https://bugs.openjdk.java.net/browse/JDK-6791812
--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
* @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 in which case its absolute value indicates the
+ * number of milliseconds before the epoch
*
* @throws SecurityException
* If a security manager exists and its {@link
The weird thing here is that if this method were invoked on a file last
modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
file does not exist or whether its last-modified time is the epoch. It seems to
me that if the file does not exist it would be better to throw a
FileNotFoundException but that is not an issue for JDK 9 at this stage of game.
Thanks,
Brian
