JDK-1243331 : ThreadGroup method setMaxPriority has two bugs
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.0,1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_1,solaris_2.4
  • CPU: sparc
  • Submitted: 1996-03-25
  • Updated: 1999-08-26
  • Resolved: 1999-08-26
Related Reports
Duplicate :  
Duplicate :  
Description
Method setMaxPriority of class ThreadGroup is not consistent in
its treatment of maximum priority relative to class Thread:

(a) If the argument is less than Thread.MIN_PRIORITY, it should
    signal an IllegalArgumentException, not quietly replace the
    argument with Thread.MIN_PRIORITY.
(b) Instead of requiring the maxPriority to decrease monotonically,
    it should allow the maxPriority to be set to any value not greater
    than the maxPriority of its parent.

I recommend the following new definition:

    public final synchronized void setMaxPriority(int newMaxPriority) {
	checkAccess();
	if (newMaxPriority < MIN_PRIORITY) {
	    throw new IllegalArgumentException();
	}
	int limit = (parent != null) ? parent.maxPriority : Thread.MAX_PRIORITY;
	if (newMaxPriority <= limit) {
	    maxPriority = newMaxPriority;
	}
	for (int i = 0 ; i < ngroups ; i++) {
	    groups[i].setMaxPriority(newMaxPriority);
	}
    }

Comments
PUBLIC COMMENTS ThreadGroup method setMaxPriority has two bugs
10-06-2004

EVALUATION Should look into fixing bugs in this report, but don't want API changes. timothy.lindholm@Eng 1996-12-03 I checked the spec and the implementation. It turns out that the two are currently in violent disagreement. Correcting the implementation will solve the first of the two problems, and partially solve the second. It's unfortunate that attempting to set a ThreadGroup's max priority higher than its parent's will silently set its max priority to its parent's, but c'est la vie. It's really not worth changing the spec. joshua.bloch@Eng 1997-08-06 Given the amount of time we've lived with this bug, it doesn't seem productive to fix it in isolation. I'm closing it as a duplicate of a catchall bug for tightening up thread specs. joshua.bloch@Eng 1999-08-26
26-08-1999