Name: skT45625 Date: 06/15/2000


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)
======================================================================