java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)

The problem is that some java.awt.* (that is, shared) classes, specifically,
EventQueue, TextComponent, and TextLine, have code that casts a Toolkit to a
sun.awt.SunToolkit to call methods only found in the SunToolkit implementation.
This violates the genericity of the shared classes, by having references
to the sun.awt.SunToolkit implementation. An example of this code, as found
in the java.awt.EventQueue class, is:

    public void postEvent(AWTEvent theEvent) {
        ((SunToolkit)Toolkit.getDefaultToolkit()).flushPendingEvents();
        postEventPrivate(theEvent);
    }

If you create a custom toolkit, by extending java.awt.Toolkit, then the code
will now blow up with a class cast exception, because your toolkit is not a
sun.awt.SunToolkit. You could extend sun.awt.Toolkit with your custom
toolkit to get around the problem, but then your code is specific to
the sun implementation of awt. As well, the documenation about toolkit
just talks about extending java.awt.Toolkit, not that will be required
to extend sun.awt.Toolkit instead to prevent your code from blowing up.

This was not a problem in 1.1.x, and the code runs flawlessly there. Only
in 1.2.x, and I believe it is still a problem in 1.3.x, does this become
a problem.

In the Java documentation there is a section called "Why Developers Should Not
Write Programs That Call 'sun' Packages", that explains that coding to
sun.* implementations, instead of the generic java.* ones, may mean the
code will not run on all platforms. Well in this toolkit situation, Sun is
forcing us to do just what they said we are not to do. This needs to be
rectified.
(Review ID: 106202) 
======================================================================

Have your custom toolkit extend sun.awt.SunToolkit instead of java.awt.Toolkit
======================================================================

Commit to fix in Tiger.  
 xxxxx@xxxxx  2001-08-14

This problem is already fixed in merlin when headless was introduced.  Closing it out as a duplicate of headless.
 xxxxx@xxxxx  2001-11-08

The work-around of extending the sun.awt.SunToolkit instead of the java.awt.Toolkit
does not work in 1.3.0. SunToolkit has added a method called getGlobalCursorManager()
which is abstract, so you have to put an implementation in your subclass. If you
return null, then the code blows up with a null pointer exception. If you try and return a
GlobalCursorManager, you cannot do new GlobalCursorManager(), because it is an
abstract class. You would have to know the class that implements that manager in
order to get the subclass working (assuming there are no other gotchas). The
situation seems to be getting worse.

1.
http://www.alphaworks.ibm.com/tech/remoteawtforjava/

I looked around and noticed that IBM Alphaworks' RAWT
implementation since jdk1.2 reimplements the java.awt
interface (as opposed to just implementing a Toolkit).
Please see the following link for a comment about what they
changed when moving from JDK1.1 to JDK1.2+.  (Alan Wecker is
the lead of the remoteawt project.)

http://www.alphaworks.ibm.com/forum/remoteawt.nsf/discussion_archived_nav/EFEA9A81AB4B96E9C6495C24A20333A9?OpenDocument

2.
http://www.progsoc.uts.edu.au/~rheise/projects/rheise.os/
http://www.progsoc.uts.edu.au/~rheise/projects/SwingToolkit/

Ryan Heise is working on a Java OS of sorts, built on top of
the Kaffe VM.  Part of this OS includes a Swing Desktop.
Get the archive and then look at

rheise.os-0.1.6-pre1/other_software/SwingToolkit-0.1.4/docs/known-problems.txt

which says "SwingToolkit doesn't work with jdk 1.2".

3.
http://developer.kde.org/language-bindings/java/qtawt/developer.html

Okay, they're just working with JDK1.1 at the moment, and
apparantly haven't even tried JDK1.2.

4.
http://www.bmsi.com/tuipeer/

"The tuipeer version does not yet support Java 2."

5.
http://www.gjt.org/javadoc/org/gjt/shark/awt/SToolkit.html

I've had trouble finding the author or additional
information on this package.

6.
http://www.eteks.com/pja/en/index.jsp

The PJA Toolkit is a "headless" AWT implementation.  It
works under JDK1.3, but the author (Emmanuel Puybaret) wrote
to me:  "PJA is for offscreen imaging so it doesn't need
cursors. [...] In JDK 1.2, there was the same problem with
the class GraphicsEnvironment that was expected by
java.awt.Font to be an instance of SunGraphicsEnvironment.
That's why PJAGraphicsEnvironment inherits from
SunGraphicsEnvironment, and that PJA can't be 100% pure Java
because it shouldn't use this class...".  This makes it
sound like the problem is bigger than I feared.

Please vote for this bug to allow Jesktop to render emulated AWT widgets it's Swing desktop.

It is nasty way to do things, but you can reimplement the 
static crud in java.awt.Toolkit by writing a new 
implementation, and putting it in the class path before the 
standard java libraries.

A similar thing was done with Jsh (I think) - It 
reimplements the java.lang.System class, and the docs 
specify that you MUST put their implementation first in the 
class path.

Like I said, it's not pretty, but maybe it's a possibility 
until Sun get round to fixing this problem...