This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Tom Tromey <tromey@cygnus.com> writes: > Also, my understanding is that Classpath uses JNI for native methods. > This is much slower than our approach. I was thinking along the lines of using their Java code as is and replacing their native libraries with CNI libraries. Is there more to it than that? > No -- the runtime doesn't include a VM. Doesn't mean that it couldn't though right? It would be a piece of work even without jitting (which would seem to be kinda overkill in the context of gcj) but it could be done right? > This support would probably be pretty easy. libtool already has a > library that acts as a portability layer over dlopen(). Okay I'm trying to imagine how it would work ... let say I have a class foo.java that I want an app I compiled with gcj to load and instantiate. Is the idea to compile this to foo.o (using gcj), link it to foo.so and then maybe have the java.lang.ClassLoader implementation in your runtime library load it using dlopen? I don't see how this could work. If I have code that uses the class foo in my original program then there will be symbols generated in the application like foo::bar, but these won't be valid symbols. Won't the compiler have to know which Java classes being used are going to be loaded dynamically and have the generated code use dlsym before trying to access the symbols from foo? Sorry if my limited understanding of how dynamic linking works is preventing me from seeing how it would work. > We're trying to make this happen, but it is largely up to how the egcs > maintainers feel about it. Licensing plays a role here too. I don't > really know the current state of this discussion. Are you saying that you'd rather have it be a part of the egcs project? Wouldn't it be more visible as its own entity? I can see how being a part of egcs would make it unnecessary to implement all the infrastructure an independent project would need. > I'll try to get this document on the web sometime soon. Not sure how > soon I can do it; there's a lot going on. I could email you a copy if > getting html in email won't make you retch. I can wait for it to appear on the website, thanks anyways. Regards, -- Tom Reilly Live Software, Inc http://www.livesoftware.com