>>>>> "Arnaud" == Arnaud Vandyck <[EMAIL PROTECTED]> writes:
>> If you follow the typical BC compilation approach, libgcj won't care >> what the so files are called. Arnaud> everything is resolved in the database file? I'll try to read the Arnaud> documents you provide. Yeah. The database maps class file contents (as represented by a hash code) to the name of a .so file. When defineClass() is called, libgcj looks up the class contents in the database, and if it is found, it opens the .so and uses the class from it. If the class contents are not found in the database, libgcj falls back to the interpreter. So, the way this works is that the application runs unmodified, and finds its classes however it ordinarily would. Where exactly they come from doesn't matter. And, since the database just maps contents to shared libraries, the location of the libraries themselves is also unimportant. That's the high level view... there are a lot of details of course, for instance how we ensure that the compiled code remains typesafe even when loaded into a malicious runtime environment; or how we ensure that loading a class twice with different class loaders works properly. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
