Re: Working On Classpath

[Thomas Fitzsimmons]

On Wed, 2004-05-26 at 17:47, Andrew John Hughes wrote:
> 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).

Right, but we can't make all default threads daemons, or programs will
exit right away.  The two non-daemon threads in a typical AWT program
are EventDispatchThread and GtkMainThread.  I'm wondering if we should
make GtkMainThread a daemon, and have the exit criteria for AWT programs
be that all threads except EventDispatchThread are daemons, all
EventQueues are empty, and all top-level windows have been disposed.

Tom