I talked about why concurrency is hard, how the Java Concurrency Framework (java.util.concurrent) solves many of these difficulties, and how CFConcurrent can help.
View the slides -- This includes the slides as well as code demonstrating how to use the Java Concurrency Framework directly, without CFConcurrent
During the presentation, folks asked fantastic questions. A few of them I couldn't answer at the time.
When you set a timeout on Future.get( timeout, timeUnit ), is the thread cancelled if the timeout occurs?
I mistakenly said that a timeout implies a cancellation. It does not. You can catch the timeout exception, then call Future.cancel( true ). However, this does not necessarily cause that running thread to die. In fact, it's quite possible to write a Task that never dies (if you write stupid code like this)
In this example above, you can attempt to cancel this Future, but you will be unsuccessful and your task will run until you restart your server.
Given perhaps a more realistic example
In this example, you'll get different results depending on the timing of the cancellation. If the timeout happens while ColdFusion is attempting to connect to the database, then you'll likely see a "connection error" and the task will fail. However, if the timeout happens after the connection succeeds, and while the query is running and CF is waiting on the results, then this code will execute to completion, even though your call to get( timeout, timeUnit ) will throw a timeout exception and control will be returned to you immediately upon that timeout.
Conclusion: write your code such that if the timeout does occur, that even if the code does eventually run to completion, it doesn't adversely affect your application.
I answered that "no, it does not", and that perhaps in the future once Java introduces closures they'll consider revisiting these APIs. Sean Corfield's opinion is that no, they will not. The reason is that if you pass a callback to get() (or for that matter, to submit()), then you lose control of the result. If you're passing a callback, that probably means you want to do something else after the task completes; in this case, simply do it in the task itself! Callbacks would introduce additional complexity and difficulty in monitoring the execution's completion, and java.util.concurrent is built to be as simple to reason about control flow as possible. So: will they introduce callbacks? I don't know. Is it a good idea? I agree with Sean: no, it is not.