This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: patches to re-direct _Jv_RegisterClass
- To: Per Bothner <per at bothner dot com>
- Subject: Re: patches to re-direct _Jv_RegisterClass
- From: Tom Tromey <tromey at redhat dot com>
- Date: 17 Jul 2001 19:02:19 -0600
- Cc: "Anthony Green" <green at redhat dot com>, <java-patches at gcc dot gnu dot org>
- References: <m2u218owwn.fsf@kelso.bothner.com> <871yocarlq.fsf@creche.redhat.com> <m2n16y4g3v.fsf@kelso.bothner.com> <87lmmh3g6a.fsf@creche.redhat.com> <m2ofrdbqu0.fsf@kelso.bothner.com> <87r8vtsvl5.fsf@creche.redhat.com> <000001c1069a$9ff5c960$5be6b4cd@cygnus.com> <m2lmm19sk8.fsf@kelso.bothner.com>
- Reply-To: tromey at redhat dot com
>>>>> "Per" == Per Bothner <per@bothner.com> writes:
Per> I'm not sure about the convention mapping package prefixes to
Per> library names in VMClassLoader::findClass. Is it actually used?
I've used it. But I think there's no way to know whether anybody else
uses it, unless they find and report a bug.
Per> A model closer to Sun's extensions mechanism would be to just
Per> search $prefix/share/gcj/*.jar, if it hasn't already been
Per> registered.
I don't follow. We're loading .so's, not .jar's. We could load every
.so we find, looking for the symbol. However, that is probably very
expensive.
Tom