Hi Andreas, I figured it out: JRE 10.0 last modified time with milli-second resolution while JRE 8.0 and earlier provide it with second resolution (though it provides it in milli-seconds). I can confirm that the change fixes the test with JRE 10.0. All the best, Bernd On 08/21/2018 03:23 PM, Bernd Rinn wrote: > Hi Andreas, > > On 08/21/2018 10:11 AM, Andreas Tille wrote: >> Hi Bernd, >> >> On Sun, Aug 19, 2018 at 03:25:46PM +0200, Bernd Rinn wrote: >>> Yes, sis-base needs to be updated to 18.08.0. This library is in the GIT >>> repository in directory >>> >>> https://sissource.ethz.ch/sispub/jhdf5/tree/master/libs/prod >>> >>> You can find the version also at: >>> >>> https://sissource.ethz.ch/sispub/base/tags/18.08.0 >> >> Thanks for this information. I've checked with this tag, but the test >> fails the same way as the previous commit. Most of the tests went fine, >> but: >> >> ... >> Application: base >> Version: UNKNOWN* >> Java VM: OpenJDK 64-Bit Server VM (v10.0.2+13-Debian-1) >> CPU Architecture: amd64 >> OS: Linux (v4.17.0-1-amd64) >> Test class: NamingThreadPoolExecutorTest >> >> Running testNamedPool >> Running testDaemonize >> Running testSetNamedThreadFactory >> Running testSetThreadFactory >> Running testSetThreadFactoryFailed >> Running testThreadDefaultNames >> Running testSubmitNamedRunnable >> Running testExecuteNamedRunnable >> Running testExecuteNamedMyRunnable >> Running testSubmitNamedCallable >> Running testSubmitMyNamedCallable >> Running testSubmitNamedCallables >> Running testSubmitQueuedNamedCallables >> Tests OK! >> >> Application: base >> Version: UNKNOWN* >> Java VM: OpenJDK 64-Bit Server VM (v10.0.2+13-Debian-1) >> CPU Architecture: amd64 >> OS: Linux (v4.17.0-1-amd64) >> Test class: UnixTests >> >> Running testGetLinkInfoRegularFile >> Exception in thread "main" java.lang.AssertionError: expected:<1534838541776> but was:<1534838541000> >> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) >> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) >> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) >> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:170) >> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:177) >> at ch.systemsx.cisd.base.unix.UnixTests.testGetLinkInfoRegularFile(UnixTests.java:59) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at ch.systemsx.cisd.base.unix.UnixTests.main(UnixTests.java:324) >> at ch.systemsx.cisd.base.AllTests.main(AllTests.java:55) >> >> >> Are you able to reproduce this at your site? Please note that at Debian >> package build time network access is permitted. So in case this test >> would require any network access I would need to deactivate it. > > No, I can't reproduce this in our test enviornment. It looks like > java.io.File of your build of OpenJDK reports last modified time with > milli-second resolution while ours reports it with resolution 1s. I > changed the precision of the test now. > > Can you please check with the current HEAD whether the issue still occurs? > > Bernd
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature