JDK-4189292 : (thread spec) ThreadGroup and Thread need better and tighter specs
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.0,1.2.0,1.3.0,1.4.2,5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS:
    generic,solaris_1,solaris_2.4,windows_xp generic,solaris_1,solaris_2.4,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 1998-11-11
  • Updated: 2024-10-09
  • Resolved: 2022-06-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-1243331 - ThreadGroup method setMaxPriority has two bugs
Relates :  
JDK-4404519 - (spec thread) Thread.setDaemon() should not be allowed after the thread terminates
Relates :  
JDK-1243764 - Better interface for getting and counting threads and thread groups
Relates :  
JDK-4168811 - (thread) ThreadGroup is not empty after last Thread dies
Relates :  
JDK-4175101 - (thread) What is the ThreadGroup of a dead thread?
Relates :  
JDK-4229558 - (thread) ThreadGroup.activeCount vs ThreadGroup.enumerate on 1.1 vs 1.2
Relates :  
JDK-4109242 - (thread spec) Thread.activeCount() does not define "active"
Relates :  
JDK-4078440 - (thread) Thread class should have getState() method
Relates :  
JDK-4300827 - (spec thread) ThreadDeath should note that stop is @deprecated
Relates :  
JDK-4310779 - (spec thread) Incomplete spec for Thread.{sleep(),join()} signatures that take arguments
Relates :  
JDK-6416721 - (spec thread) Fix Thread.yield() javadoc
Relates :  
JDK-4082405 - (thread) Thread.enumerate() yields wrong result (it counts inactive threads)
Relates :  
JDK-4528152 - (thread spec) Do unstarted daemon threads prevent VM termination?
Relates :  
JDK-5109912 - (spec thread) Thread.enumerate() and Thread.activeCount() don't match ThreadGroup methods
Relates :  
JDK-6378434 - (thread) IllegalThreadStateException invoking Thread.start after getting OOME (jdk5.0)
Relates :  
JDK-4162694 - (thread) ThreadGroup.activeCount() doesn't always reach 0 after stop() called
Description
Thread states and state transitions are never really specified.
Many aspects of ThreadGroup behavior are not tightly specified.  This
bug is meant to be a catch all for various other bugs that are effects of these spec problems.
Comments
Thread and ThreadGroup have been significant re-specified in Java 19 (JEP 425, Project Loom). So I think we can finally close this issue.
18-06-2022
Thread and ThreadGroup will be significantly re-specified as part of Project Loom.
02-09-2020
I'll look more carefully - why these JCK tests are excluded with this issue (this is very long standing exclude). Until this is not analysed, I think it would be better to remove 'tck-red-9' label from the issue. However, I think 'conformance' label should stay anyway, because bugs in the spec is conformance issue.
27-10-2014
'conformance' and 'tck-red-9' labels were added, because the following test cases is excluded from JCK due to this issue: api/java_lang/ThreadGroup/setMaxPriority01/setMaxPriority0106/setMaxPriority0106.html
23-10-2014
EVALUATION The goals for this "umbrella bug" about a year ago were overtaken by a thousand and one unmaskable interrupts, although a modest few improvements to Thread* have made it into Mustang and a few other improvements related to this CR are in flight. There is also much more certainty about certain APIs that should get no implicit encouragement via improved doc sans general class doc "advice", assuming they can't be formally deprecated. But this CR cannot be addressed in toto in time for the current major release. Even with a miracle of resource infusion there is too much publication and discussion/refinement process left to accomplish and the public APIs involved cannot be tweaked so late in the Mustang cycle anyway.
05-05-2006
EVALUATION This would certainly be nice.
11-06-2004