Interrupt Handlers

[Eric Kolotyluk]

No, my example is not a polling task and not exactly a clean-up
action, my *concern
*is something more general, it's about the unnecessary boilerplate that
Java sometimes imposes on us...

Remember the days before we had try-with-resources, and we would attempt to
close resources in the finally { } block, only to be punished with the
compiler complaining about catching the IOException? That always frustrated
me. Java try-with-resources was a blessing in several ways... including
reducing compiler intemperance and unnecessary boilerplate...

For decades, it has bugged me that whenever I do Thread.sleep() I have to
deal with the InterruptedException in unpleasant ways. Yes, I generally use
Thread.sleep() in testing situations, but not always. While I rarely call
wait() any more, this would be a similar example where I might want to say

object.wait(cause -> {}) // eat/ignore the exception
object.wait(cause -> dealWithTheInterruptSomeOtherWay())

So my concern is not with just sleep(), but any blocking API that may throw
an InterruptedException. Similarly, in any situation where I might get a
CancellationException.

My reference to Structured Concurrency and StructuredExectutor
CompletionHandler was simply that it *resembled *a solution to a Java
frustration that is decades old, and it resembles the pattern I am talking
about now. Indeed, my experience with Scala has shown how useful some
Functional Programming patterns can be, where Completion Handlers can be
expressed as Lambdas...

Beyond Java 18, I hope there are more subtle improvements to the language
and libraries that give us further opportunities to reduce the boilerplate
in Java. Indeed, one of the attractions to using Scala and Kotlin is the
reduction in boilerplate.

When I think back to 1995, Java Concurrency has surely come a long way, and
I hope it continues to get better, easier, safer, more (fun)tional...

Cheers, Eric

On Tue, Dec 21, 2021 at 3:02 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 21/12/2021 00:41, Eric Kolotyluk wrote:
> > :
> >
> > Maybe not the best example in the world, because it's a unit test, but it
> > can lead to less boilerplate. I have seen this pattern in other
> frameworks,
> > but dealing with StructuredExecturor CompletionHandlers inspired me to
> use
> > it in my own APIs. It would be nice to see this pattern adopted in other
> > Java APIs. For example, I would like to be able to write
> >
> > Runnable task3 = () -> {
> >      for (int i = 0; i < 10; i++) {
> >          if (Thread.interrupted()) break;
> >          else Thread.sleep(Duration.ofMillis(10), cause -> {});
> >      }
> > };
> >
> > Is there an existing JEP where I can make this feature request?
> >
>
> Is your issue with Thread.sleep throwing an exception or a more general
> need to invoke cleanup actions when someone is trying to cancel?
>
> Thread.sleep is usually found in test code (like your example). When
> testing then it's normal for a test runner to interrupt threads when the
> test timeout has been reached and it wants the (failed) test to finish.
> Your example seems to be something else, maybe it's a polling task that
> uses Thread.sleep with a short duration to avoid consuming cycles?
>
> As regards cleanup actions then it is something that was partially
> explored in the initial prototypes of SC in 2018. The motivation there
> wasn't "boileplate", instead it was allow cleanup actions to run without
> concern the cleanup action would itself be cancelled/interrupted. It's
> an area that we may look at it again.
>
> -Alan
>