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");
                                     

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
                                     

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;
                                     

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.