JDK-4109242 : (thread spec) Thread.activeCount() does not define "active"
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.0,7
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic,unknown
  • Submitted: 1998-02-04
  • Updated: 2024-10-09
  • Resolved: 2022-06-18
Related Reports
Relates :  
JDK-4083644 - Thread and ThreadGroup don't implement/deprecate according to JLS 20.20
Relates :  
JDK-4494726 - (thread) ThreadGroup.enumerate() does not return all active threads
Relates :  
JDK-4189292 - (thread spec) ThreadGroup and Thread need better and tighter specs
Description
Unclear language speicification make it very hard to define and implement the class java.lang.ThreadGroup()

1. activeCount(), the API indicates it should return the count of active threads
  in this thread group. But there is no definition active. Actually, the thread
  can be started or stopped, or just exits any time. There is no semantic mean
  for that.

2. There are 8 methods in the ThreadGroup API have never been implemented. They
   are threadsCount(), allThreadsCount(), groupsCount(), allGroupsCount(),
   threads(), allThreads(), groups(), allGroups()
   Is there any real need for these methods? What is semantics for the methods?
   Is it safe to do so? Since we need to take snapshot of thread group, which
   is likely to prevent a high priority thread to start or stop.

3. Since most os does not provide equivalent concept, it is very hard to map
   the definition to os primitives.

We should make the api more clear before we provide the implementation. This bug
is response for bug 4083644.
Comments
Thread and ThreadGroup has been significantly re-specified in Java 19. The Thread.activeCount and ThreadGroup.activeCount methods have been re-specified to to drop the term "active", instead the methods are specified to return an estimate of the number of live platform threads, where "live" is linked to Thread::isAlive. So I think we can close this issue now.
18-06-2022
EVALUATION It appears possible to tease the definition of "active" away from any context within the Thread class and properly define it tersely within ThreadGroup. That is, it appears possible to kill off any notion of "active thread" while addressing the specific request by defining "active ThreadGroup." This CR is another piece of the "umbrella" request about Thread and ThreadGroup specification improvement as CR 4189292. This defect correction should not be taken as encouragement to use the ThreadGroup class. See item #53 of Josh Bloch's "Effective Java" for more details about the hazards of using this class.
13-04-2007
EVALUATION Reported items 2 and 3 are no longer issues. The disputed methods do not exist. The remaining issue regarding activeCount() is a specific instance of the more generic bug 4189292 which requests better spec for both Thread and ThreadGroup.
14-07-2006
EVALUATION The Thread specification is clearly inadequate. This is is demonstrated by the fact that there have been so many questions about it. In particular, only part of the semantics of threads is documented outside of the API. The API documentation itself is not sufficient. This needs to be addressed by adding more rigorous specification to the API in the JLS and documenting the special role of threads in the JVMS. This will take time, but we need to get started. gilad.bracha@eng 1998-02-05 I'd argue that the above evaluation, while correct in what it says, is not to the point of this bug report. The report notes that the ThreadGroup APIs are badly documented, and some methods are essentially unimplemented or are useless as implemented. None of this reflects on class Thread any more than a collection class reflects on the heap storage that underlies it. Historically speaking, ThreadGroups were done by someone who was essentially not in contact with the people implementing threads. While class Thread is not well-specified, there is nobody left at JavaSoft who even knows what the intent was behind parts of the ThreadGroup API. Documenting Thread will not fix the problems with ThreadGroup. The most important thing to do for ThreadGroup is to find it an owner who will try to understand its purpose and how it is being used. timothy.lindholm@Eng 1998-02-05 Fair enough. Certainly I have not figured out concrete answers to the specific questions raised in by this bug. Nevertheless, I see this as part of a larger issue. And yes, ThreadGroups need an owner. gilad.bracha@eng 1998-02-05
05-02-1998