Problems with Swing on Kaffe

Glynn Clements glynn at
Sun Jul 19 04:00:38 PDT 1998

Nathan Meyers wrote:

> > > > plus you wouldn't break existing applications.
> > > > Aren't those methods on Toolkit you choose not to implement
> > > > required by the PersonalJava standard you claim to conform to?
> > >
> > > Since peers are completely "hidden" implementation, it shouldn't break any app.
> > > The Toolkit createXX methods are protected, and I don't see how they would be
> > > used by apps.
> >
> > Correct me if I've misunderstood what's going on here, but all of the
> > java.awt.* `widget' classes work by calling methods of the peer which
> > they create (using `getToolkit().createFoo(this)') in their
> > addNotify() method.
> >
> > How can a Toolkit be implemented without providing classes which
> > implement the Peer interfaces?
> The way Swing does it: by opening a bare-naked window and rendering the
> components into it. A Swing button is not a Motif/Win32 button. It isn't
> even a subwindow in your GUI. It's just some designated real estate in
> the GUI; the toolkit takes care of figuring out when something is
> happening that affects the component -- such as clicking a mouse button
> over the real estate belonging to a GUI button.

I think that you've misunderstood me. I'm not asking about whether the
Toolkit is implemented in terms of e.g. Xt widgets. I'm asking about
how the Toolkit provides the objects which the various Component
subclasses use to implement themeselves.

The implementation of e.g. a Button is determined by the ButtonPeer that it
obtains by calling getToolkit().createButton().  As the JDK docs say:

   o getToolkit  
 public Toolkit getToolkit()

   Gets the toolkit of this component. Note that the frame that contains
          a component controls which toolkit is used by that component. 
          Therefore if the component is moved from one frame to another,
          the toolkit it uses may change.
                The toolkit of this component.

IOW, you can force any of the Component subclasses to use a different
peer by overriding the getToolkit() method of the parent frame. In
order for this to work, the Component needs to use only the methods
defined for its peer.

Running the following test program with kaffe:

import java.awt.*;

public class Test
	public static void main(String[] args)
		Frame f = new Frame();
		Button b = new Button("Hello");
		f.add("Center", b);

produces the output `java.awt.Toolkit', which is rather odd as
java.awt.Toolkit is defined as:

	public abstract class Toolkit

The bottom line is that the statement:

> > > Since peers are completely "hidden" implementation, it shouldn't break any app.

is incorrect. Peers are *not* completely hidden.

Consider the following test program. MyToolkit is a dummy toolkit,
where all methods print a message indicating that they have been
called, then return null/0/false.

class MyFrame extends Frame
	private static Toolkit toolkit;

	public Toolkit getToolkit()
		if (toolkit == null)
			toolkit = new MyToolkit();
		return toolkit;

public class Test
	public static void main(String[] args)
		Frame f = new MyFrame();
		Button b = new Button("Hello");

		f.setLayout(new BorderLayout());
		f.add("Center", b);

If I try this with Sun's JDK, I get the output: 

* createButton
	at Test.main(

If I try it with kaffe-1.0b1, it creates and displays a button, just
as if I hadn't overriden the getToolkit() method in MyFrame.

Now, I note that Sun have removed the definitions of the peer
interfaces from the JDK-1.1.6 documentation. However, the definition
of java.awt.Toolkit still states that it implements the createXxx
methods which have return types of xxxPeer, and the definition of
java.awt.Component::getToolkit still states that the Toolkit is
determined by the containing frame.

Glynn Clements <glynn at>

More information about the kaffe mailing list