Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

Alan Bateman Alan.Bateman at
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 fails.
> That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
> and 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(
>                  at Issue225.main(
> 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 mailing list