Date: Fri, 18 Jan 2019 12:04:54 +0000 From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 235018] java/openjdk8: adding millisecond resolution to get/setLastModified breaks many apps Message-ID: <bug-235018-8522-0n3ZZL5Xqz@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235018-8522@https.bugs.freebsd.org/bugzilla/> References: <bug-235018-8522@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235018 --- Comment #6 from Michael Osipov <michael.osipov@siemens.com> --- I think we need to break things down here because here we have several issu= es 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 re= main as-is: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/f0b93fbd8cf8/src/solaris/na= tive/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, Ja= nuary 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 i= t 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235018-8522-0n3ZZL5Xqz>