Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Jan 2019 10:26:01 +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-tzUZm3bDgb@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 #2 from Michael Osipov <michael.osipov@siemens.com> ---
This affects java.io.UnixFileSystem and probably java.io.File. Well,
File#lastModified() has millisecond precision. Looking at the code in Java =
11
you see:

> JNIEXPORT jlong JNICALL
> Java_java_io_UnixFileSystem_getLastModifiedTime(JNIEnv *env, jobject this,
>                                                 jobject file)
> {
>     jlong rv =3D 0;
>=20
>     WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
>         struct stat64 sb;
>         if (stat64(path, &sb) =3D=3D 0) {
> #if defined(_AIX)
>             rv =3D  (jlong)sb.st_mtime * 1000;
>             rv +=3D (jlong)sb.st_mtime_n / 1000000;
> #elif defined(MACOSX)
>             rv  =3D (jlong)sb.st_mtimespec.tv_sec * 1000;
>             rv +=3D (jlong)sb.st_mtimespec.tv_nsec / 1000000;
> #else
>             rv  =3D (jlong)sb.st_mtim.tv_sec * 1000;
>             rv +=3D (jlong)sb.st_mtim.tv_nsec / 1000000;
> #endif
>         }
>     } END_PLATFORM_STRING(env, path);
>     return rv;
> }

This is the default now.

How does it break Tomcat, I don't get it? The RFC you are quoting is invali=
d.
Look into RFC 7231, chapter 7.1.1.

--=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-tzUZm3bDgb>