Re: Working On Classpath

[Andrew John Hughes]

On Sun, 2004-05-23 at 22:50, Mark Wielaard wrote:
> In general the easiest way to get started is to take one of the
> development environments based on GNU Classpath (gcj, kaffe, ...) and
> take one of the free software projects written in java and see whether
> or not they work or not. And then try to figure out which functionality
> would be needed to get them working. See also:
> http://sources.redhat.com/rhug/
> http://www.kaffe.org/compatibility_applications.shtml
> 
> Cheers,
> 
> Mark
Hi,

Apologies for spamming the list last time -- seems the mailing list has
been lagging a little recently.

Well, I've been using a mix of gcj and sablevm with classpath for a
while, but I've just put on Jam with the latest CVS version of Classpath
so I can work on it (the former being maintained system-wide by Debian).
Testing existing apps. does seem like the best route, and there are a
few Java projects I'd like to see work with a Free base (namely Ant and
Tomcat) and a fair few of my own apps that I can also test (a fair range
of assignment work, including AWT, Swing, RMI, TCP, UDP and servlets). 
There are a few things I've spotted already, which I don't know if you
know about or not:

* I've managed to get some very basic AWT and Swing examples running
(just a button in a frame).  AWT seems to work almost flawlessly (which
is a big improvement on last time I tried this), but seems to not handle
window closing events correctly.  The Swing one is unfortunately still
very buggy (throwing up both some display glitches and GTK errors), but
I suppose this is to be expected.  One problem with Swing is that the
access privileges of the getContentPane() method in JDialog seem to be
wrong (compared with Sun's docs), preventing some of my code compiling. 
The main question is how is the AWT/Swing code being handled?  I know
recent code has been coming upstream from GCJ -- is this the case for
all AWT/Swing code?  I don't really want to handle anything here if its
already being handled elsewhere.  Another problem I noticed -- as soon
as a toolkit is instantiated, the code doesn't exit anymore, presumably
because some thread is hanging on -- even something as simple as
getDefaultToolkit().getScreenSize() needs a Ctrl+C.  It doesn't seem to
be a JVM problem (same on Jam, Sable and gij) so must be something in
the shared gcj/classpath code for the AWT (either in the main code or in
the peers).
* Both Tomcat and Ant seem to want tools.jar for Sun's compiler classes,
which seems a bizarre dependency (especially considering the package is
com.sun) -- is there a Free software version of this or some way of
disabling it? Ant works fine without, until the compile stage (so its
fairly required).  Tomcat only needs it for JSP AFAICS.

Anyway, I'll start posting patches once the copyright assignment is
through,

Thanks,
-- 
Andrew :-)
 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
 
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.

signature.asc
Description: This is a digitally signed message part