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

[David Holmes]

Hi Alan,

I've always thought ThreadGroups were a good idea that were never 
communicated very well. The notion of a ThreadGroup as a security 
context potentially had some value that was never truly realized.

On 4/06/2020 4:40 am, Alan Bateman wrote:
> On 03/06/2020 18:47, Paul Sandoz wrote:
>> 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.
>>
> I've held back from deprecating ThreadGroup in its entirety, at least 
> for now, because the notion of a group of threads, or even tree of 
> groups, isn't too toxic and there may be herding or other grouping needs 
> in the future that might mean ThreadGroup comes backs in a different 
> form. Also anything we do here has to take the debugger support into 
> consideration, hence the prototype efforts to reconstitute the list of 
> threads in order to keeping JVMTI working.

Thread groups as a concept certainly seem useful just from a 
partitioning perspective when it comes to managing large numbers of 
threads. I assume that Java EE environments (and similarly styled 
execution environments) still create new thread groups and threads for 
each distinct execution context? In which case I would expect the 
ability to enumerate the active group members may have some value in 
those environments. But if noone uses them any more ...

> One reason for deprecating these methods is that they are inheriting racy.

Yes taking an array as input was a very bad API design for these 
methods. One of the great historical travesties in this area is that the 
JLS First Edition listed an alternate API that returned an appropriately 
sized array, but those APIs were never actually implemented in the JDK. :(

David
-----

> Deprecating the specific methods mentioned here, plus a few others that 
> I didn't mention in this discussions, means that the only non-deprecated 
> methods would be  getName, getParent, parentOf, checkAccess and 
> uncaughtException. Yes, that is kinda sad but it doesn't preclude us 
> from deprecating the entire class in the future.
> 
> -Alan.
> 
> 
>