classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working On Classpath


From: Thomas Fitzsimmons
Subject: Re: Working On Classpath
Date: Wed, 26 May 2004 13:44:32 -0400

On Sun, 2004-05-23 at 22:04, Andrew John Hughes wrote:
> 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,
> 

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)

Modified versions of ant and tomcat that work with GCJ are available
from the RHUG project:

http://sources.redhat.com/rhug/

We're also doing work that will eventually allow these packages to run
unmodified on GCJ.

>  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.

This is fixed on GCJ's java-gui-branch.

>   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. 

This is also fixed on java-gui-branch.

> 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?

Yes, almost all AWT and Swing development is currently done on GCJ's
java-gui-branch.  We do java-gui-branch-to-Classpath merges about once
every three months.

>   I don't really want to handle anything here if its
> already being handled elsewhere.

It's probably best to work on the java-gui-branch then.  I've done some
work to simplify setting up a comfortable development environment.  See:

http://people.redhat.com/fitzsim/gcj-and-jhbuild.html

for an explanation.

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

Yes, this is still a problem.  I haven't figured out yet what should be
the exit criteria for a GUI app.  Sun's JVM seems to exit some time
after the last window is disposed.  In my test applications I explicitly
call System.exit, but we should make our AWT implementation work like
Sun's when dispose is called.  It will take some experimentation -- do
you want to give it a go?

> * 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.
> 

People have worked around this dependency before.  See the RHUG version
of ant for instance.

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

Excellent!

Tom






reply via email to

[Prev in Thread] Current Thread [Next in Thread]