Others may have more informative answers, but a quick search found this StackOverflow Q&A, with links to a couple of earlier ones: https://stackoverflow.com/questions/10510300/java-thread-pool-executor-monitoring

Why is GitHub Search the literal worst. (－‸ლ)

Thanks, @U0CMVHBL2 :) Trying to check this out but SO appears to be down for maintenance on my side. I will say that I'm able to monitor the FixedThreadPool just fine. I'm still resisting putting a small Java program together just to prove that this isn't something weird with my environment but I'm suspicious that I'm just not understanding the reflection/module behavior well enough.

It is pretty much Google's reason for being, so if they are bad at it, then someone else will eat their lunch.

You know I bet this is some kind of wrapper class that has the scheduled thread executor as a member or something…

https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/share/classes/java/util/concurrent/Executors.java#L681

getPoolSize exists on ThreadPoolExecutor, which is what newFixedThreadPool actually returns. But it doesn't exist on ExecutorService. newSingleThreadScheduledExecutor does not return an instance of the ThreadPoolExecutor class.

LOL >

>     /**
> >     * A wrapper class that exposes only the ExecutorService methods
> >     * of an ExecutorService implementation.
> >     */
> > 

@U2FRKM4TW Yep yep.

So I guess I'm going about this wrong here. My hope was to have a scheduler executor service for scheduling future tasks in a non-blocking way that I could emit metrics on from a separate thread like how big the queue is, how many tasks have completed, etc. Is there a better Java concurrency utility for accomplishing this with?

Actually I bet it's literally this simple

(.getPoolSize (Executors/newScheduledThreadPool 1))

I think the reason for the Delegate class is because of the line > Unlike the otherwise equivalent newScheduledThreadPool(1) the returned executor is guaranteed not to be reconfigurable to use additional threads. So that would necessitate hiding its instance methods behind the Delegate class such that they can't be messed with, I suppose.

Baeldung has steered me wrong… 🙀 🙀 🙀

I do feel like I was lied to a bit by that javadoc though… :)