Hi -- I'm hoping somebody can point me to the correct dev list to notify of an inaccuracy in the java 7 and 8 javadoc. ThreadPoolExecutor lines 170 and 171 state, "And the value of the maximumPoolSize therefore doesn't have any effect." However, getTask (called by a new thread when firstTask is null) clearly references the maximumPoolSize on line 1032 (I'm looking at 1.7.0_10 and a version of 1.8.0). It looks like the statement was true in java 6.
In addition the the javadoc being slightly inaccurate, the ThreadPoolExecutor behavior seems to have changed in a way I've not seen documented. If it has been, I'd appreciate a link to the documentation so I can read over it. But the situation is this:
Suppose a ThreadPoolExecutor which uses an unbounded blocking queue has a corePoolSize and maximumPoolSize of 4. Suppose I submit 5 tasks so that 1 task is queued, then set the corePoolSize to 5. In java6, this would cause an additional thread to be allocated and the task would get executed. In java7, this doesn't happen (apparently bounded by the check against maximumPoolSize mentioned above). It's actually a little worse than that as the Thread gets allocated & added to the pool, but it does not handle the waiting task. Though the case where corePoolSize > maximumPoolSize seems exceptional, it is possible. In my case, I was trying to allow another Thread in the ThreadPoolExecutor so that my current thread could block & wait on a newly submitted thread to return. It deadlocked instead.
I worked up a bit of code to demonstrate the change in behavior. It runs to completion in both cases, but the java7 version takes longer because it has to re-use a Thread. If you put a breakpoint on ThreadPoolExecutor:1128 (the call to processWorkerExit), you should see Threads die & exit the pool while there is still work in the pool.