Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
Alan.Bateman at oracle.com
Fri Nov 24 15:53:30 UTC 2017
On 24/11/2017 14:53, Schaef, Martin wrote:
> We are experiencing a problem with the following test case:
> Depending on which gcc version we use to compile OpenJDK, the assertion in https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L397 fails.
> That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
> and java.io.File.lastModified() return results with a different precision.
> We root-caused it to the following code block in UnixNativeDispatcher.c:
> The test case at the bottom of this email can be used to reproduce the behavior. When using a JDK compiled with gcc 4.1.2, the test prints:
> nio 1511387180000
> io 1511387180000
> But when using a JDK compiled with gcc 4.4.6, the code returns:
> nio 1511387187817
> io 1511387187000
> Exception in thread "main" java.lang.RuntimeException: 1511387187817 != 1511387187000
> at Issue225.testLastModified(Issue225.java:33)
> at Issue225.main(Issue225.java:11)
> In comparison, the OracleJDK binaries as downloaded from the website behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure that both methods behave the same, we propose to remove the block in UnixNativeDispatcher.c (see attached patch).
We should the higher precision time stamps when available, it's just
awkward that it gets compiled or not depending on the header files.
It sounds like you are looking to drop this support (I can't quite tell
as your patch was dropped by the mailing list). Instead it would be
better to see if we can change File.lastLastModifiedTime to use the
higher precision timestamp if possible. It will of course need to be
converted to millis.
More information about the core-libs-dev