Merging in Classpath and PocketLinux AWT (Was Re: [kaffe] CVS kaffe (dalibor): Implemented -Xbooclasspath options)
robilad at kaffe.org
Thu May 20 08:06:03 PDT 2004
Kaffe CVS wrote:
> PatchSet 4755
> Date: 2004/05/20 13:51:38
> Author: dalibor
> Branch: HEAD
> Tag: (none)
> Implemented -Xbooclasspath options
> 2004-05-20 Dalibor Topic <robilad at kaffe.org>
> * kaffe/kaffe/main.c:
> (options) Added -Xbootclasspath and Xbootclasspath/a
> option handling.
> (usage) Added new options. Fixed intendation problems.
> Reported by: Julio M. Merino Vidal <jmmv at menta.net>
-Xbooclasspath/p was actually implement for quite a while, just not
really documented. I think a few people asked for this.
In the interesting short run, this should enable us to proceed with
merging in Kaffe's Pocketlinux AWT implementations and GNU Classpath's
AWT implementations side by side without having to do a lot of
retrofitting of kaffe's peerless implementation first. I'm looking at
Jim Huang's work to see what he did to get classpath's AWT running on Kaffe.
This should make the implementation of the ideas  for further AWT
merges quite straight forward. The goal is to have the AWT
implementation selectable at compile and/or runtime. Here's my plan:
1) move AWT files in current libraries/javalib into their own
subdirectory, like libraries/javalib/awt-implementations/kaffe/.
2) Build it separately from the rest of class library as kaffe-awt.jar.
3) make sure it gets picked up on the bootclasspath by default.
4) merge in Classpath's AWT and Swing into the libraries/javalib as the
'normal' AWT. The reason for that is that Classpath implements more
up-to-date AWT APIs than Kaffe's AWT does. By making Classpath's AWT the
'default' API, we can allow more programs to be built against kaffe.
That doesn't necessarily mean that Classpath's AWT becomes the 'default'
AWT right now. But it means that we can follow GNU Classpath's rapid
developement in this area, and have very nice things like the portable
AWT-over-frambuffers implementation from Odonata running on kaffe.
5) Add an option to pick up the desired AWT on the command line.
-with-awt=kaffe would let you run kaffe's AWT, --with-awt=classpath
would let you run classpath's AWT.
6) Merge in Pocketlinux AWT in its own directory. (Merge in Rudolph.
Merge in DirectFB AWT. Or any other GPL-comaptible AWT toolkit ;)
7) Add pocketlinux option.
8) Eventualy, add a --with-awt-backend option to kaffe binary to pick
the native AWT backend for Kaffe and Pocketlinux AWT implementations.
That's my plan for the next couple of days. If Jim Pick agrees, we may
be able to put it in into 1.1.5, even, if it turns out to work well.
There is one draw-back: if you're using Kaffe's AWT in an embedded
system, you'll have to work around Classpath's AWT being compiled in by
default. You should be able to do that by removing the awt.files file
from the default profile, though, or by defining your own class libray
profile withuot AWT and adding the separate kaffe-awt.jar.
More information about the kaffe