Re: Working On Classpath

[Andrew John Hughes]

On Wed, 2004-05-26 at 18:44, Thomas Fitzsimmons wrote:
> 
> 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.
> 
I'm going to take a look now -- I think its great someone is doing this,
although it probably should have been Apache to start with.  Given the
length of time that the Free Java projects have now been active, it
amazes me that so little consideration is given to alternate VMs and
compilers by the Java community, especially for FOSS.  I know Ant
supports alternate compilers, but this wouldn't exactly be very clear to
someone who wants to use Ant in the same way as make ('make' -->
'ant').  One of the reasons that I think the autoconf/make stuff is
still a superior solution, even for Java, is that these solutions tend
to detect what a user actually has, instead of defaulting to Sun's JVM. 
Apologies if some of this is wrong, but this is the impression I, and I
guess other users, get of the Ant/Tomcat situation.

> 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.
...
> 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.
> 
I guessed as much, which was why I was wary of committing any patches
for the small problems I've noticed.  It seems it would be best for me
to get this set up as you say, and contribute any AWT/Swing patches to
gcj rather than Classpath -- does this need a separate copyright
assignment?
> >   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?
> 
I'd be happy to have a look.  Even the following causes the problem:

import java.awt.Toolkit;
 
public class AWTGetScreenSize
{
 
    public static void main(String[] args)
    {
        System.out.println(Toolkit.getDefaultToolkit().getScreenSize());
    }
 
}

Which is possibly one of the most minimal examples you could give for
this (dropping .getScreenSize() would probably drop it down even more).
From looking at the code, I know the instantiating the toolkit via
getDefaultToolkit() spawns the underlying GDK event threads, so it may
be related to this -- the only way to really find out is to trace the
calls, I suppose.  AFAIK, Java apps. should die when all non-daemon
threads have stopped (i.e. the GC can still be running, as its a
daemon).

> Tom

Cheers,
-- 
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