Re: [Arnaud Vandyck] Re: gcj4 changes : Please Comment

[Tom Tromey <tromey@redhat.com>]

>>>>> "Arnaud" == Arnaud Vandyck <avdyk@debian.org> 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