[Bug 235018] java/openjdk8: adding millisecond resolution to get/setLastModified breaks many apps

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235018

--- Comment #6 from Michael Osipov <michael.osipov at siemens.com> ---
I think we need to break things down here because here we have several issues
mixed:

1. Yes, I do agree that this change is wrong because the code isn't maintain
and not portable. Moreover, this isn't something platform-specific. I have
found the changes in Java 10 for millisecond precision, but Java 8 shall remain
as-is:
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/f0b93fbd8cf8/src/solaris/native/java/io/UnixFileSystem_md.c
2. You are application is flawed
(ifUnmodifiedSinceTime.equals(lastModifiedTime)) and you are relying on an
implementation detail instead on the documentation:

> The Javadoc clearly says: A long value representing the time the file was last  modified, measured in milliseconds since the epoch (00:00:00 GMT, January 1,  1970), or 0L if the file does not exist or if an I/O error occurs

It may or may not contain millisecond precision, but the entire value is
milliseconds. HTTP dates values are in second resolution, yet you convert it to
a field with millisecond resolution. You must truncate both values down to
seconds to make it comparable. Everything else is just flawed. If you would
rely on NIO2 or new date time API with Instants you'd have the same issue in
Java 8.

-- 
You are receiving this mail because:
You are the assignee for the bug.