ThreadGroup.enumerate/activeCount - any good reason not to deprecate?

[Paul Sandoz]

It’s tempting to go all out and investigate the deprecation of (not for removal) ThreadGroup in its entirety, and also deprecate the Thread constructors accepting ThreadGroup, related methods in SecurityManager, etc. I suspect that’s probably more work than you want to take on right now, and maybe there is still some salvageable functionality.

Paul.

> On Jun 3, 2020, at 10:13 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> Does ThreadGroup have any fans out there? I'm looking to deprecate its enumerate, activeXXXCount, and list methods. Also Thread.enumerate and activeCount. I'm trying to identify if there are any important usages of these APIs that would suggest they shouldn't be deprecated. A static analysis of the artifacts in Maven isn't coming up with much.
> 
> One reason for deprecating these methods is that they are inheriting racy. The javadoc has recommended for many releases that they be only used for debugging and monitoring purposes. The javadoc has warned, since at least JDK 1.1, that the enumerate methods silently ignore the case where the array isn't large enough.
> 
> Another reason for deprecating these methods is that they are obsolete, even for monitoring purposes. Java 5 added ThreadMXBean, ThreadInfo and better ways to get information on live threads.
> 
> Finally, there is "threads" array keeping a reference to every Thread in the group. That array is problematic for several performance reasons, and ultimately it would be nice to have that go away. Making that go away will require re-implementing a number of JVMTI functions that operate on threads groups but there are alternative ways to implement those (Serguei Spitsyn did an initial prototype to check this).
> 
> For now, I'm just trying to see if there are any important usages of these APIs that I may have missed.
> 
> -Alan.