Re: Binary compatibility and finding compiled classes

[Bryce McKinlay <mckinlay at redhat dot com>]

Tom Tromey wrote:

> One thing we'd like to be able to do with the new binary compatibility
> code is compile a .jar to a .so, drop it somewhere, and then have the
> application pick it up without excessive configuration.
>
> There have been a few different proposals, and implementations, of
> this idea.  I think it would be useful to clear some of this up now,
> before the next release, so we can at least be clear about what is
> supported and what is experimental; maybe we can also remove anything
> we know we don't want.
>
> Current attempts:
>
> - libgcj will compute a .so's name from the class name and try to
>  dlopen it.  We've done this for a long time.  It does cause
>  problems, for instance we can load a .so compiled against a
>  different libgcj, thus pulling in that libgcj and wreaking havoc.
>
>  In my working BC tree, I re-enabled the "duplicate class
>  registration" abort just so I could detect this happening... in
>  fact I suspect we must keep that error for the time being, in order
>  to properly die when we accidentally load a non-BC library.
>  
When we have an "ABI version" metadata field, we can check that the 
library we're opening is really compatible. I think the real problem 
here is that we load these specially-named .so's from standard system 
dirs. I think it would be better to make a special location for 
dynamically opened Java .so's, such as /usr/lib/java or /usr/lib/gcj (to 
allow libs to be installed in arbitrary locations, this could actually 
be "any system LD path" with /java appended to it. An version hierarchy 
could be established within that to prevent loading incompatible libs.

I'm not defending the current naming mechanism, however, it clearly has 
problems - apart from the versioning issues theres the inability to name 
them to match .jar's, and have different packages in a single .so. We 
need something more scalable.

> I would like to do some experimenting in this area soon; now that I've
> got Eclipse 3 running with the interpreter I'm itching to see it
> running precompiled.
>  
You and 10,000 others :)

Regards

Bryce