The core pool size set to 1, which AFAIK means the maximum number of threads on this executor will always 1. As a consequence, you'll never get two delayed tasks to run concurrently. Is that on purpose ? @Background has always had a parallel behavior, if we want serial behavior which should make a clear distinction.

I didn't know which value to set here. Maybe a big one (ex: Integer.MAX_VALUE) or maybe we should create a ScheduledExecutorService each time we call executeDelayed ? Do you know the effect of a value of 0 for the core pool size ? It's not said in the java doc and it doesn't seem to rise an exception.

It may be a good thing to let the user defines how many threads he wants because this is typically a parameter that changes according to the needs.

Maybe with another optional parameter in the @Background annotation. If the user doesn't fill this parameter, assign a default value to 5 for the corePoolSize.

What do you think about this idea?

I don't think it's a good idea as it means each @Background could be responsible of the creation of a thread pool. That could cause a performance issue, and it could be hard to understand from a developer point of view.

I would prefer to define a value. Something like that :

• [Runtime.availableProcessors()](http://developer.android.com/reference/java/lang/Runtime.html#availableProcessors(\)) * 2
• Math.ceil([Runtime.availableProcessors()](http://developer.android.com/reference/java/lang/Runtime.html#availableProcessors%28%29%29 * 1.5d)

What do you think ?

I think Mathieu is right. The more so as a developper will be able to change the ScheduledExecutorService using the static method of BackgroundExecutor. Regarding the value to set, I have no idea.

👍