JDK-6497629 : (thread) ThreadGroup.setMaxPriority checks against last set maximum, not parent's maximum
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-11-27
  • Updated: 2017-05-16
  • Resolved: 2007-06-22
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 Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u10Fixed 7 b15Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-4708197 - (thread) ThreadGroup.setMaxPriority changes priority if param is out of range
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 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
02-03-2007
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");
02-03-2007
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.
27-11-2006
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;
27-11-2006