java.security.Security loading providers from ltdl managed symbol tables?

Fri Sep 26 01:00:00 GMT 2003

I've compiled with GCJ 3.3, the jcraft ssh (jsch) implementation. 
The examples too link properly.
jsch depends on JCE, for which Bouncy Castle provides providers. Both
JDK1.1 (jce-jdk11-119.tar.gz) as well as JDK1.3(jce-jdk13-119.tar.gz) compile
properly and link correctly with jsch.
The JDK1.1 Bouncy Castle provides a few too many classes in the java.util.* range
already available in libgcj, and causes gcj to complain about double registration of
classes.
The JDK1.3 Bouncy Castle overlaps partially, but only with interfaces apparently, so
no double registration errors get triggered.
When trying to execute, jsch tries to get the Diffie-Hellman key pair classes:
 myKpairGen=KeyPairGenerator.getInstance("DH");
 myKeyAgree=KeyAgreement.getInstance("DH");
Which are available through Bouncy Castle JCE, but which fail to get registered with
java.security.Security (I've linked them whole-archive):
 static
 {
 String base = System.getProperty("gnu.classpath.home.url");
 loadProviders(base, System.getProperty("gnu.classpath.vm.shortname"));
 loadProviders(base, "classpath");
 }
loadProviders seem to revolve around jar that are at particular URLs:
InputStream fin = new URL(secfilestr).openStream();
In my impression, none of the natively compiled providers will be loaded with the
code above. It looks as if only classpath (bytecode) classes will be loaded, while
the classes available through the executable's own symbol tables (or even linked
shared objects) will fail to be loaded.
Is there a way to change java.security.Security, so that it will load providers from
its own native symbol tables managed by ltdl?