Binary compatibility and finding compiled classes
Bryce McKinlay
mckinlay@redhat.com
Thu Oct 7 22:00:00 GMT 2004
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
More information about the Java
mailing list