coolness

[Tom Tromey]

>> Also, my understanding is that Classpath uses JNI for native
>> methods.  This is much slower than our approach.

Thomas> I was thinking along the lines of using their Java code as is
Thomas> and replacing their native libraries with CNI libraries.  Is
Thomas> there more to it than that?

For libraries other than java.lang, there's probably nothing more to
it.  The `gcjh' program has some limitations; if their code doesn't
match what it expects then you'll have problems.  (Most code
conforms.)

For java.lang you also need to make sure that object layout is the
same, and you need to implement the functions to which the compiler
generates calls.

>> No -- the runtime doesn't include a VM.

Thomas> Doesn't mean that it couldn't though right?  It would be a
Thomas> piece of work even without jitting (which would seem to be
Thomas> kinda overkill in the context of gcj) but it could be done
Thomas> right?

Yes, it could be done.

Thomas> Is the idea to compile this to foo.o (using gcj), link it to
Thomas> foo.so and then maybe have the java.lang.ClassLoader
Thomas> implementation in your runtime library load it using dlopen?

Yes.

Thomas> I don't see how this could work.  If I have code that uses the
Thomas> class foo in my original program then there will be symbols
Thomas> generated in the application like foo::bar, but these won't be
Thomas> valid symbols.  Won't the compiler have to know which Java
Thomas> classes being used are going to be loaded dynamically and have
Thomas> the generated code use dlsym before trying to access the
Thomas> symbols from foo?

In this case you would link that library in at link time.  The link
will fail if your program has unresolved symbols.

An example of doing this at runtime would be if you wrote a new
ResourceBundle.  You could compile it separately and put it in some
magic place.  Then the runtime would automatically find this resource
when doing its search.

Your program wouldn't have any explicit references to symbols in this
class.  Instead it would be handled at runtime.

Thomas> Are you saying that you'd rather have it be a part of the egcs
Thomas> project?  Wouldn't it be more visible as its own entity?

Speaking for myself, I'd rather have it in egcs.  I think that would
lead to less problem reports of the sort I easily tire of answering.
To me, personally, maximizing visibility isn't the goal (which is not
to say that minimizing visibility is...).

Thomas> I can see how being a part of egcs would make it unnecessary
Thomas> to implement all the infrastructure an independent project
Thomas> would need.

This isn't really an issue.  We have all the infrastructure.
Duplicating it (for the cvs stuff) or extracting it (the build stuff)
isn't really a big deal.  I'm more concerned with making the thing
easy to get and easy to build.

Having to fetch two pieces (egcs plus the runtime) and build them
separately (or, worse, patch one to include the other) is more error
prone than fetching just one package.

Tom