JDK-4887645 : Remove "awt.threadgroup" system property
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2003-07-08
  • Updated: 2011-01-14
  • Resolved: 2011-03-07
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 7
7 b126Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description

Name: jk109818			Date: 07/08/2003


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [Version 5.1.2600]


A DESCRIPTION OF THE PROBLEM :
The evaluation of Bug Id 4063022 mentions
an "awt.threadgroup" system property that would allow for
an alternative means of overriding the uncaughtException
method. RFE 4672338 is a request to document this
funcationality that is in the "In progress, bug" statis
(i.e. an open RFE).

This functionality was implemented in the no-argument
constructor for sun.awt.SunToolkit which is the superclass
of sun.awt.windows.WToolkit. These classes are loaded
using the bootstrap class loader. Therefore the following
code (which executes perfectly when copied to an
application program) fails to find the user class
specified by the awt.threadgroup system property:

============= START OF BLOCK COPIED CORE API CODE =======
 /* If awt.threadgroup is set to class name the instance of
	 * this class is created (should be subclass of
ThreadGroup)
	 * and EventDispatchThread is created inside of it
	 *
	 * If loaded class overrides uncaughtException
instance
	 * handles all uncaught exception on
EventDispatchThread
	 */
	ThreadGroup threadGroup = null;
        String tgName = System.getProperty
("awt.threadgroup", "");

	if (tgName.length() != 0) {
	    try {
		Constructor ctor = Class.forName(tgName).
		    getConstructor(new Class[]
{String.class});
		threadGroup = (ThreadGroup)ctor.newInstance
(new Object[] {"AWT-ThreadGroup"});
	    } catch (Exception e) {
		System.err.println("Failed loading " +
tgName + ": " + e);
	    }
	}
================END OF CODE EXAMPLE ======================

This may be a historical error as I believe this code may
have been in place before the new bootstrap/extension/user
classloader design was implemented.







STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. replace the name of the awt.threadgroup class with any
Threadgroup subclass on your classpath
2. recompile and execute
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Now that I understand the problem I expect it to fail, but
the specified class is supposed to be used as the
ThreadGroup to which runtime exceptions and errors thrown
in the event dispatch thread are passed when the
uncaughtException method is invoked by the JVM.

Here is some typical output:

awt.toolkit = sun.awt.windows.WToolkit
sun.awt.SunToolkit classloader = null
user classloader = sun.misc.Launcher$AppClassLoader@bac748
threadGroup = com.javarules.util.ThreadGroupSubclass
[name=AWT-ThreadGroup,maxpri=10]
Failed loading com.javarules.util.ThreadGroupSubclass:
java.lang.ClassNotFoundException: com/javarules/util/ThreadGroupSubclass


The output clearly shows the code in sun.awt.SunToolkit
work. The problem is simply that the bootstrap classloader
cannot be used to load user classes.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Failed loading com.javarules.util.ThreadGroupSubclass:
java.lang.ClassNotFoundException: c
om/javarules/util/ThreadGroupSubclass

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.lang.reflect.Constructor;
import javax.swing.*;
import sun.awt.SunToolkit;

public class Test {
   public static void main(final String args[]) {

       System.setProperty("awt.threadgroup",
                          "com.javarules.util.ThreadGroupSubclass");
      // System.setProperty("awt.threadgroup",
      //                    "java.lang.Object");
       System.out.println("awt.toolkit = " + System.getProperty
("awt.toolkit"));
       System.out.println("sun.awt.SunToolkit classloader = " +
                           SunToolkit.class.getClassLoader());
       System.out.println("user classloader = " +
                           Test.class.getClassLoader());
      
//================= BLOCK COPIED FROM sun.awt.SunToolKit ======================
      /* If awt.threadgroup is set to class name the instance of
	 * this class is created (should be subclass of ThreadGroup)
	 * and EventDispatchThread is created inside of it
	 *
	 * If loaded class overrides uncaughtException instance
	 * handles all uncaught exception on EventDispatchThread
	 */
	ThreadGroup threadGroup = null;
        String tgName = System.getProperty("awt.threadgroup", "");

	if (tgName.length() != 0) {
	    try {
		Constructor ctor = Class.forName(tgName).
		    getConstructor(new Class[] {String.class});
		threadGroup = (ThreadGroup)ctor.newInstance(new Object[] {"AWT-
ThreadGroup"});
	    } catch (Exception e) {
		System.err.println("Failed loading " + tgName + ": " + e);
	    }
	}

  //================= BLOCK COPIED FROM sun.awt.SunToolKit
======================

    // Worked?
      System.out.println("threadGroup = " + threadGroup);

  
       new JFrame("");
    }
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
use sun.awt.exception.handler system property
(the "temporary hack")
(Review ID: 160904) 
======================================================================

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/jdk/rev/6e4d9f4466f6
17-01-2011

EVALUATION After the fix for 6727884, all the exceptions occurred on EDT are handled via standard Thread.UncaughtExceptionHandler API, so there's no use in awt.threadgroup system property.
15-11-2010