他说他改变主意了。
改变什么主意了？他之前的主意是什么？
在 Doug 说他是故意这样写的之后，Martin 说：
It's intentional。哦，原来是故意的呀。
那个时候他的主意就是：大佬都说了，这样写是考虑过的，肯定没有问题。
现在他的主意是：如果 isDone 方法返回了 true，那么 get 方法应该明确的返回结果值，而不会抛出 IE 异常。
需要注意的是，这个时候对于 BUG 的描述已经发生变化了。
从“FutureTask.isDone 方法在任务还没有完成的时候就会返回 true”变成了“如果
isDone 方法返回了 true，那么 get 方法应该明确的返回结果值，而不会抛出 IE 异常”。
然后 David 靓仔给出了一个最简单的解决方案：
最简单的解决方案就是先检查状态，再检查当前线程是否中断。
然后，这个 BUG 由 Martin 同学进行了修复：
修复的代码可以先不看，下面一小节我会给大家做个对比。
他修复的同时还小心翼翼的要求 Doug 祝福他，为他站个台。
最后，Martin 同学说他已经提交给了 jsr166，预计在 JDK 9 版本进行修复。
出于好奇，我在 JDK 的源码中搜索了一下 Martin 同学的名字，本以为是个青铜，没想到是个王者，失敬失敬：
代码对比
既然说在 JDK 9 中对该 BUG 进行了修复，那么带大家对比一下 JDK 9/8 的代码。
java.util.concurrent.FutureTask#awaitDone：
可以看到，JDK 9 把检查是否中断的操作延后了一步。
代码修改为这样后，把之前的那段示例代码放到 JDK 9 上面跑一下，你会惊奇的发现，没有抛出异常了。
因为源码里面判断 COMPLETING 的操作在判断线程中断标识之前：
它说：isDone 方法已经告诉使用者任务已经完成了，那么调用 get 方法的时候我们就不应该什么都不返回或者抛出一个 IE 异常。
这行注释想要表达的东西，就是上面一小节的 BUG 里面我们在讨论的事情。写这行注释的人，就是 Martin 同学。
当我了解了这个 BUG 的来龙去脉之后，又突然间在 JDK 9 的源码里面看到这个注释的时候，有一种很神奇的感觉。
就是一种源码说：you feel me?
我马上心领神会：I get you。
挺好。
