Tim Peierls

Seems reasonable to me. "Abandon" is a good word for this, with the implication that the task (supplier) is left to its own devices. Might want to add a warning...

Issue #213 is another example of a user being surprised by this behavior. (In that case, there's also a surprise about how the ordering of policies affects behavior.)

A separately configurable initial delay and jitter seems like overkill. How about `DelayablePolicy.withInitialDelay(boolean)` that when true adds its first delay __before__ the first attempt? (When false, behaves normally.)

Yes, these don't seem to pull their weight, neither - a separate policy for an initial delay, nor - separate methods on `RetryPolicy` or a supertype to configure an initial...

I see the applicability, but that use case is in the context of a more general periodic scheduling apparatus (transitions throughout the day, different patterns for different days of the...

FWIW, here's what @jlouvel wrote about this (to the "code" listserv) back in September 2009: > Hi guys, > > Ivan Gorgiev came across a subtle multi-threading issue as described...

### Corrected comment (original comment below) The sketch below is __broken__. The simplest and best fix to `parse` (and the one I should have mentioned right away) is to wrap...

Also, even though the double-checked locking is correct here, I see no compelling reason to initialize `regexVariables` lazily. It would be simpler to make it a final field and initialize...

Restlet does __not__ refer to [Spring's `SerializationUtils`](https://www.javadoc.io/doc/org.springframework/spring-core/3.2.8.RELEASE/org/springframework/util/SerializationUtils.html), which appears to be at the heart of the vulnerability.

accural -> accrual