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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
