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.bate...@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.
