United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6497629 (thread) ThreadGroup.setMaxPriority checks against last set maximum, not parent's maximum
JDK-6497629 : (thread) ThreadGroup.setMaxPriority checks against last set maximum, not parent's maximum

Details
Type:
Bug
Submit Date:
2006-11-27
Status:
Resolved
Updated Date:
2010-05-11
Project Name:
JDK
Resolved Date:
2007-06-22
Component:
core-libs
OS:
generic
Sub-Component:
java.lang
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
While fixing 4708197 it was noticed that the ThreadGroup.setMaxPriority javadoc asserting that the parent's maximum priority is an upper limit for a new max priority value (if a parent ThreadGroup is defined). But the current ThreadGroup instance max priority is used instead.

                                    

Comments
SUGGESTED FIX

This is the suggested fix for this CR combined with the fix for 4708197:

+++ 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

As with CR 4708197, this is a mismatch between what the spec says happens and what actually happens. Making the implementation match the spec is actually less restrictive, as it allows new maximums lower and subsequently higher, as long as both values are not greater than the parent maximum, while currently the maximum is "racheted" downward and can never be moved back up no matter what the relation to the parent group maximum.
                                     
2006-11-27
EVALUATION

However, as a reviewer pointed out, it's conceivable that an application is somehow dependent on the current behavior with this defect. A workaround for this case is straight forward, by introducing a "grandchild" group after setting the maximum priority so that the maximum priority of the grandchild ThreadGroup cannot be set to a higher value subsequently, like this:

ThreadGroup child = new ThreadGroup("child");
child.setMaxPriority(...)
ThreadGroup grandChild = new ThreadGroup(child, "grandChild");
                                     
2007-03-02
SUGGESTED FIX

Here's the webrev of the final fix and new regression test for this CR and CR 4708197:

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



Hardware and Software, Engineered to Work Together