使用DelayQueue需实现Delayed接口，被迫引入Clock是否有优化方案？

我最近刚好找到了完全契合需求的DelayQueue。虽然我也认可ScheduledExecutorService通常是更优的选择，但因为我手里已经有一个现成的执行器实例，而且想要对时序实现完全的掌控，所以最终还是决定要实现Delayed接口。

但这就带来了一个小麻烦：我不得不引入一个基于java.time.Clock封装的轻量时钟实例来获取当前时间，代码大概是这样的：

private final Instant expires;
private final Clock clock; // 太不优雅了！！！

public long getDelay(TimeUnit timeUnit) {
    return timeUnit.convert(
        Duration.between(clock.instant(), expires)
            .toMillis(), 
        TimeUnit.MILLISECONDS
    );
}

说真的，这种写法真的让人有点难受——就为了实现Delayed接口的getDelay方法，硬生生多了一个Clock依赖，总感觉有点冗余。不过转念一想，引入Clock也不是完全没好处，比如在测试场景下可以很方便地替换成固定时钟来模拟不同时间点，但从代码简洁性来说，这确实算不上优雅的实现。

内容的提问来源于stack exchange，提问作者maaartinus