* Future might not even be a ListenableFuture, just a plain Future. That said, similar
         * problems can exist with methods like FutureTask.done(), not to mention slow calls to
         * Thread.interrupt() (as discussed in InterruptibleTask). At the end of the day, it's
         * unlikely that cancel() will be slow, so we can probably get away with calling it while

  //   system scheduling and as such we could either miss our deadline, or unpark() could be delayed
  //   so that it looks like we timed out even though we didn't. For comparison FutureTask respects
  //   completion preferably and AQS is non-deterministic (depends on where in the queue the waiter
  //   is). If we wanted to be strict about it, we could store the unpark() time in the Waiter node

  //   system scheduling and as such we could either miss our deadline, or unpark() could be delayed
  //   so that it looks like we timed out even though we didn't. For comparison FutureTask respects
  //   completion preferably and AQS is non-deterministic (depends on where in the queue the waiter
  //   is). If we wanted to be strict about it, we could store the unpark() time in the Waiter node

builder(); public void FailOnTimeout(org.junit.runners.model.Statement, long); private void FailOnTimeout(FailOnTimeout$Builder, org.junit.runners.model.Statement); public void evaluate() throws Throwable; private Throwable getResult(java.util.concurrent.FutureTask, Thread); private Exception createTimeoutExcepti(Thread); private StackTraceElement[] getStackTrace(Thread); private Thread getStuckThread(Thread); private java.util.List getThreadsInGroup(ThreadGroup); private long cpuTime(Thread); } org/junit...