Re: 3.3 branch, 3.3.1, 3.4, etc

[Tom Tromey <tromey at redhat dot com>]

>>>>> ">" == Dhek Bhun Kho <bhun@chello.nl> writes:

>> Is it at all necessary? (imho) It's better to spend time I guess on
>> things that actually affect compilation of java code and gcj
>> itself.

Our goal is to provide a complete Java environment.  So, this will
eventually include a javadoc replacement.  Whether this is the "most
important" task of course depends on the metric by which you measure
such things.  It isn't at the top of my list, but if someone writes a
patch, or if I find I've finished the things I consider to be more
important, it will happen.

>> I did have a question I was hoping somebody might answer. Like what
>> is the preferred method of implementing the gcj java classes? Java
>> code (and a lot of memory loss) or interfacing cni?

In general we prefer efficient java implementation.  That isn't a
contradiction in terms.

For some classes which are known to be performance-sensitive, we will
do something special.  For instance see the String implementation.

>> Cause this set up would work wouldn't it? 
>> public class StringTokenizer {
>> private NatTokenizer natTokenizer;

Yes, something like this would work.  Or, you could just make all the
methods in StringTokenizer native.  That would be simpler.

But to get this into cvs you'd have to make a case for it.  In general
we prefer to keep our classes in sync with Classpath.  We believe this
typically lowers our maintenance cost, as we pick up bug fixes and
other enhancements more cheaply.

>> I am still reading a bit about cni and such, but couldn't find real
>> documents about like what is preferred, like either cni or jni.

If you need native code, we prefer CNI.  JNI is possible in some
limited situations.

>> Is the current speed of gcj compiled programs due to the amounts of
>> native code?

I'd say it is more that we precompile all the Java code.  The fact
that the C++/Java barrier is so thin is definitely helpful, but you
can't really attribute the bulk of the performance to that.

>> Hopefully it's not too bothersome for all these messages to appear
>> (and why does gcc keep version bumping?)

If you mean the nightly builds, that's so that we can tell more
precisely what gcc snapshot was used.

Tom