United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4708197 : (thread) ThreadGroup.setMaxPriority changes priority if param is out of range

Details
Type:
Bug
Submit Date:
2002-06-26
Status:
Closed
Updated Date:
2007-06-22
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
core-libs
OS:
generic
Sub-Component:
java.lang
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0,5.0
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
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 
api/java_lang/ThreadGroup/setMaxPriority01/setMaxPriority0105/setMaxPriority0105.html
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:
=================setMaxPriority0105.java=================
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

======================================================================

                                    

Comments
SUGGESTED FIX

A webrev of the actual fix and new regression test is here:

 http://javaweb/java/jdk/ws/libs/rev/4708197
                                     
2007-03-02
EVALUATION

The time has come to make the SE implementation match the spec with respect to ignoring out of range priority values.
                                     
2006-11-27
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;
                                     
2006-11-27
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.
                                     
2005-10-26
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
                                     
2002-11-03



Hardware and Software, Engineered to Work Together