JDK-4708197 : (thread) ThreadGroup.setMaxPriority changes priority if param is out of range
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P3
  • Affected Version: 1.4.0,5.0
  • OS: generic
  • CPU: generic
  • Submit Date: 2002-06-26
  • Updated Date: 2017-05-16
  • Resolved Date: 2011-05-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 Availabitlity Release.

To download the current JDK release, click here.
6u10Resolved 7 b15Fixed
Related Reports
Relates :  
Name: skR10005			Date: 06/26/2002

The API spec for method ThreadGroup.setMaxPriopity reads

  If the pri argument is less than Thread.MIN_PRIORITY or greater than
  Thread.MAX_PRIORITY, the maximum priority of the group remains unchanged.

The new JCK test 
checks this assertion. However, this test failed under all previous 
JDK versions up to JDK 1.4.1-rc.

To reproduce this failure, a simple example can be used:
import java.io.PrintStream;

public class setMaxPriority0105 {

    public void run(String argv[], PrintStream log, PrintStream out) {

        ThreadGroup thg = new ThreadGroup("setMaxPriority0105");
        int prio = thg.getMaxPriority();
        thg.setMaxPriority(Thread.MIN_PRIORITY - 1);
        if(prio != thg.getMaxPriority()) {
            out.println("thread group priority is changed:" + 
                    prio + "-" + thg.getMaxPriority());


    public static void main(String args[]) {
    	(new setMaxPriority0105()).run(args, System.err, System.out);

The log of execution is following:
$ javac -d . setMaxPriority0105.java
$ java -version
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b15)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b15, mixed mode)
$ $ java -cp . setMaxPriority0105
thread group priority is changed:10-1


SUGGESTED FIX A webrev of the actual fix and new regression test is here: http://javaweb/java/jdk/ws/libs/rev/4708197

SUGGESTED FIX This is the suggested fix for this CR in combination with the fix for 6497629: +++ ThreadGroup.java Mon Nov 27 14:09:19 2006 @@ -231,15 +231,14 @@ public final void setMaxPriority(int pri) { int ngroupsSnapshot; ThreadGroup[] groupsSnapshot; synchronized (this) { checkAccess(); - if (pri < Thread.MIN_PRIORITY) { - maxPriority = Thread.MIN_PRIORITY; - } else if (pri < maxPriority) { - maxPriority = pri; + if (pri < Thread.MIN_PRIORITY || pri > Thread.MAX_PRIORITY) { + return; } + maxPriority = (parent != null) ? min(pri, parent.maxPriority) : pri; ngroupsSnapshot = ngroups; if (groups != null) { groupsSnapshot = Arrays.copyOf(groups, ngroupsSnapshot); } else { groupsSnapshot = null;

EVALUATION The time has come to make the SE implementation match the spec with respect to ignoring out of range priority values.

EVALUATION Changing the spec in this case would mandate asymmetric behavior in the sense that too-low values will 'clamp' to the minimum allowed while too large will be ignored. (Mandating clamping too large values to the max allowed could conceivably break apps too, so the rationale for changing the spec would not seem to allow for making the clamping work for both limits). A spec change also tends to force all compliant implementations to change in a way that may frequently be judged less than optimal (remove "tends" if the TCK is updated). A better approach might be to simply fix the implementation at the beginning of the Java SE 7 cycle.

EVALUATION It is not clear whether the behavior or the spec should be changed. This is relatively obscure functionality and it's theoretically possible at that changing the behavior will break running apps. ###@###.### 2002-11-03