-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
29 Apr 2005 12:32:12 -0600,
Tom Tromey <[EMAIL PROTECTED]> wrote:
>>>>>> "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.
I read some mails about the location of the classmap.db file on the
Fedora mailing list[1], thanks to Mark. Is it possible to specify a
directory where we could put all the db files and gij could resolve the
mapping using the files in this directory?
I'm thinking about:
/
|-- var
|-- lib
|-- gcj
|-- classmap.d
|-- activation-1.0.jar.db
|-- activation.jar.db -> activation-1.0.jar.db
|-- ant-1.6.jar.db
|-- log4j-1.2.8.jar.db
|-- log4j-1.2.jar.db -> log4j-1.2.8.jar.db
|-- [...]
`-- velocity-1.4.jar.db
This could be very dynamic. The file can be created when the package is
built and the `package.jar.so` native library just put the db file in
/var/lib/gcj/classmap.d/.
Is this possible?
> 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.
Good to know, but I think a common location like /usr/lib/java*.jar.so
seems to be the one we'll all agree.
> 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.
That's too complicated for me, I let you resolve the `details` :-D
I'd like to thank all the (very great) people working on gcj to make
this happening!
Thanks,
[1] http://article.gmane.org/gmane.linux.redhat.fedora.java/244
- --
.''`.
: :' :rnaud
`. `'
`-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCc9x04vzFZu62tMIRAslcAJ95H9/y4xdBfViUoj8D5GsPyN4kdwCfVzG+
l6lW1CA19D7mzW2YOGFtIjE=
=GXfB
-----END PGP SIGNATURE-----
