I am frequently challenged about the seriousness of this bug and the impact that it has. It’s not the first time I try to explain that, because this bug affects LockSupport.parkNanos() it basically spreads like a virus across all the platform, but let’s see this more practically
$ grep -r -l "parkNanos" . ./java/util/concurrent/Future.java ./java/util/concurrent/FutureTask.java ./java/util/concurrent/ThreadPoolExecutor.java ./java/util/concurrent/ScheduledThreadPoolExecutor.java ./java/util/concurrent/RunnableFuture.java ./java/util/concurrent/package-info.java ./java/util/concurrent/ExecutorCompletionService.java ./java/util/concurrent/CancellationException.java ./java/util/concurrent/RunnableScheduledFuture.java ./java/util/concurrent/CompletableFuture.java ./java/util/concurrent/AbstractExecutorService.java ./javax/swing/text/JTextComponent.java ./javax/swing/SwingWorker.java ./sun/swing/text/TextComponentPrintable.java ./sun/swing/SwingUtilities2.java
Well, it does not look that bad, does it? But uhm… I guess we are missing something… who’s using this classes? And who’s using such classes? And who’s using such classes? Omg… I am getting an headhache! Almost EVERYTHING is using this! So trust me, you will be affected. Maybe you are still not believing it, but please remember that this affects also Object:wait(:long) and so, transitively, also synchronized. Wait… WOOT? Oh yeah 🙂 So lots of fun! Especially when your system, deployed on client premises, starts doing “strange” things and you are called by your (not very happy) support team.
Be aware that this bug is now fixed in JDK8 and I have no knowledge of any successful backports of it into JDK7.
The full saga, all the articles I published on the matter: