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

[Arnaud Vandyck <avdyk@debian.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

29 Apr 2005 12:32:12 -0600, 
Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "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.

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-----