Occasional ThreadLocalRandom failures on Kokoro

[briandealwis]

Our tests occasionally fail in a puzzling way on Kokoro. I've appended an extract from a recent test failure on MacOS (note that this test is apparently running JDK 1.8.0_152).

Starting process 'Gradle Test Executor 3'. Working directory: /Volumes/BuildData/tmpfs/src/github/jib/jib-plugins-common Command: /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/bin/java -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dorg.gradle.native=false -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /Volumes/BuildData/tmpfs/tmp/.gradle/caches/4.6/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 3'
Successfully started process 'Gradle Test Executor 3'
Gradle Test Executor 3 started executing tests.
com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStepTest > testRun_emptyLayersIgnored STANDARD_ERROR
    SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
    SLF4J: Defaulting to no-operation (NOP) logger implementation
    SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

com.google.cloud.tools.jib.plugins.common.ZipUtilTest > testZipSlipVulnerability_windows SKIPPED
Gradle Test Executor 3 finished executing tests.

com.google.cloud.tools.jib.tar.TarStreamBuilderTest > testToBlob_stringsAndTarArchiveEntries FAILED
    java.lang.NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom
        at java.util.concurrent.ConcurrentHashMap.fullAddCount(ConcurrentHashMap.java:2526)
        at java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2266)
        at java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1166)
        at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
        at org.mockito.internal.util.concurrent.WeakConcurrentMap.expungeStaleEntries(WeakConcurrentMap.java:127)
        at org.mockito.internal.util.concurrent.WeakConcurrentMap$WithInlinedExpunction.containsKey(WeakConcurrentMap.java:260)
        at org.mockito.internal.creation.bytebuddy.MockMethodAdvice.isMock(MockMethodAdvice.java:116)
        at org.mockito.internal.creation.bytebuddy.MockMethodAdvice.isMocked(MockMethodAdvice.java:121)
        at java.io.OutputStream.write(OutputStream.java:75)
        at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.writeRecord(TarArchiveOutputStream.java:566)
        at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:387)
        at com.google.cloud.tools.jib.tar.TarStreamBuilder.writeEntriesAsTarArchive(TarStreamBuilder.java:50)
        at com.google.cloud.tools.jib.blob.WriterBlob.writeTo(WriterBlob.java:36)
        at com.google.cloud.tools.jib.tar.TarStreamBuilderTest.verifyBlobWithoutCompression(TarStreamBuilderTest.java:193)
        at com.google.cloud.tools.jib.tar.TarStreamBuilderTest.testToBlob_stringsAndTarArchiveEntries(TarStreamBuilderTest.java:78)
306 tests completed, 1 failed, 1 skipped

[briandealwis]

I hit similar errors a couple of weeks ago, but on Linux as well as MacOS, and which magically cleared up. Unfortunately our build environments seem to be running different versions of the JDK as those tests ran on a JDK 1.8.0_171.

I wrote at the time that

the stack trace looks like JDK-8150014 (fixed in Java 9; dupes JDK-8150667, JDK-8150365).

[chanseokoh]

About using different JDK versions, we should talk the Kokoro folks and ask why.

And assuming this is JDK-8150014 as you said, I guess there's nothing much we can do except waiting for JDK >= 9?

[briandealwis]

Perhaps Kokoro provides knobs for tweaking the versions used?

20 more days to JDK11! http://www.java-countdown.xyz

[chanseokoh]

Haven't seen this for a while.