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.
