Re: gcj 3.0 post-mortem

[Tom Tromey <tromey at redhat dot com>]

Nic> - real methods names in gij stack traces

I think we've talked about something like this in terms of writing the
SecurityManager code.  Somehow it has to be possible to extract
different pieces of information from any stack frame, whether
interpreted or compiled.  I don't think anybody has a concrete
implementation plan though.  I also don't think this would make my top
4 priority list (SecurityManager might, but not stack trace info -- in
theory you could use gdb for debugging).

Nic> - facilities to support something similar to sun's extensions

I don't understand.

Nic> - better threading (new pth m:n from IBM?

We really just rely on the OS.  However, I'd definitely accept a port
to the IBM pth code if someone wanted to write it.  I couldn't guess
how hard it would be.  Maybe just configury in boehm-gc and libjava,
or maybe really hard.

In terms of personal priorities, this isn't on my list.  I'm curious
to know why you want it.

Nic> - awt: people will laugh till we have at least awt
Nic> [ ... ]
Nic> It's bad design of course, but not having AWT is the real biggie.

I agree this is important.  In fact I think AWT is the most important
missing package.  But you know how it goes: libgcj is a volunteer
project.  Well, mostly.  Some of us are paid to work on it -- but our
direction is driven by customers, and so far nobody has opted to pay
anyone to write AWT for libgcj.  So it remains partially implemented,
basically what a few of us have written in our spare time.

RMI might also be important.  We can merge that from kaffe into
Classpath and libgcj any time, though, as I understand it.  It will
probably happen first, simply because it is less work.

Tom