This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
packaged/unpackaged JNI access
- From: Heitzso <heitzso at growthmodels dot com>
- To: java at gcc dot gnu dot org
- Date: Wed, 08 Mar 2006 10:53:54 -0500
- Subject: packaged/unpackaged JNI access
I stumbled across the 1.4 jvm change that blocks
accessing unpackaged classes from packaged classes.
Normally this would not be a problem but I'm trying
to access the Quadmore TTS SAPI bridge for Win OS
integrated text-to-speech. Their provided bridge
code, both Java and jni dll library, are unpackaged.
Hence you cannot instantiate the Java JNI bridge class
from within a nice, normal, packaged class.
I can load the jni dll using System.loadLibrary(), but
cannot call the function directly due to the JVM's mangling
of the name(?). I've read that it is possible to kludge around
this with reflection but don't know how to proceed.
I can inspect the .dll with objdump and see its mangled
names.
The gotcha is although Quadmore provides the jni C source
code it must be compiled with a purchased Microsoft
C++ compiler in order to pick up the proprietary headers
provied by the $ version.
I can buy Visual C++ .Net 2003 for $60 or so and will
do that in a few minutes if I cannot sort out how to
get around this problem some other way.
Sorry for the long winded preamble. My question is:
Does gcj follow the 1.4 spec and block access across
packaged and unpackaged classes?
I know a number of magicians frequent this list and
I'm wondering if any of you know some magic trick
to access the unpackaged jni dll methods from within
a packaged class? (admittedly off topic question)
Thanks,
Heitzso