[concurrency-interest] the remove-on-cancel policy on ScheduledThreadPoolExecutor

Doug Lea dl at cs.oswego.edu
Tue Aug 31 11:51:24 EDT 2010

On 08/31/10 01:12, Sangjin Lee wrote:
> Maybe this has been discussed in the past...
> I've always been curious why ScheduledFuture.cancel() would not also remove
> tasks from the queue (so would keep them live until the delay elapses) as an
> optional behavior. I know one can override the decorateTask() method to achieve
> the same effect, but it's slightly less than optimal as you need to create an
> additional delegate object to achieve the same goal. Then I checked the upcoming
> JDK 7 changes, and there seems to be such a setting called the remove-on-cancel
> policy!
> I looked some old versions of ScheduledThreadPoolExecutor, and it seems this
> behavior was in but was removed at some point? Could someone shed light on why
> it was decided not to include it in the existing versions of JDK? And why the
> change in JDK 7? I would love to have this behavior, but I'm just curious about
> the reason behind these decisions. Thanks!

The story on this is that it was (and presumably still is)
Sun/Oracle policy not to introduce API changes between
major releases. So even though we have had a version with
setRemoveOnCancelPolicy in our jsr166 CVS for years now,
the only distributed version is in openjdk7 (as well as
the jdk7 binary snapshots). And while it is a little
painful to set up, you can always get a copy from us
(either standalone or part of jsr166.jar) and place in your
bootclasspath to use it with JDK6+. (Get it via links at


More information about the Concurrency-interest mailing list