Ahead of time compiler solutions

Fri Nov 15 14:03:00 GMT 2002

>>>>> "Philippe" == Philippe Laporte <plaporte@wgate.com> writes:

Philippe> How far is the GCJ AWT from working? How many 40-hours one
Philippe> man weeks do you think? I'm not suggesting that I already
Philippe> know how to do it, but if it's a bug or two, it's another
Philippe> matter.
It is more than a bug or two. However, it is less than "design and
implement".
Look here:
 http://rainbow.netreach.net/~sballard/japi/htmlout/h-jdk13-classpath.html
The java.awt part of this chart applies equally well to libgcj (we
share java.awt completely with Classpath).
So you can see on the java side we appear to be doing very well. The
real situation is worse, since we have a fair number of stub methods
which do nothing; japi doesn't detect this situation.
Also this neglects the peers. I'd say the peers are only 50% finished.
As for many-weeks, I really don't have a good number. Based on recent
work, it seems pretty easy to make progress. However, I've only been
fixing bugs, not adding new stuff (e.g., fixing font support or
writing GridBagLayout).
Philippe> Has GCJ been run though the JCK (TCK) or an equivalent
Philippe> (about which I'd like to hear)?
The JCK isn't available to free software java implementations. So,
no, this hasn't been done.
Instead we use Mauve, Jacks, and some regression tests in our own
tree. This combination is probably nowhere near as complete as the
JCK (or so I'd like to believe :-). (I can imagine Jacks being as
complete. But then we do poorly on Jacks...)
Philippe> Otherwise, what's your estimate of how many 40-hours one man
Philippe> weeks for the JNI method?
I've never looked at that. But man-weeks isn't the only important
metric. There is also public support and the long-term direction of
the project to consider. It's certainly preferable for the project as
a whole to have AWT completed (assuming we're facing an either-or
choice of things to work on) than to have gcj generate JNI code.
Philippe> You cannot see the use of the JNI way? Even if it weren't
Philippe> used by GCJ, it could be by Kaffe, and by so many other VMs,
Philippe> which might bring some people to GCJ who have projects were
Philippe> space is much more important than speed, at least until we
Philippe> get the Isolation API...
Oh, I can definitely see the use. And if it is implemented cleanly,
with a low long-term maintenance overhead, then I would even be in
favor of checking it in. But if you're looking to apply presumably
limited manpower to making gcj suitable for your use, I'd much prefer
it be put somewhere else. That's my preference; what you actually do
must be up to you.
Philippe> 2- TurboJ (http://www.ri.silicomp.fr/adv-dvt/java/turbo/)
Philippe> Supports up to JDK 1.1. They estimate the bring up to date
Philippe> time for one man at a year.
I didn't know they only did 1.1. gcj is mostly at 1.4, though there
are some known exceptions. On the compiler side, we don't support
strictfp (it is ignored). On the runtime side there are various warts
in addition to whatever classes or methods might be missing (not many
from the core).
Tom