JNI Unsatisified Link error with overloaded static native funtions
Hey,
This problem exists in both JDK 5 and 6 under Solaris. If you overload a static native function, the VM is not generating the correct signature for the overloaded function when it tries to resolve it. I built a debug version of JDK 6 to verify this, stopping in the routine that is called to resolve the link. The name it is passing in to that routine does not match the name generated by javah for the function. It appears to have omitted the encoded argument information that distinguishes the overloaded functions.
Here is a code snippet to better illustrate the problem.
public class Type1 {}
public class Type2 {}
public static native String Image(Type1 t);
public static native String Image(Type2 t);
...
Type1 t1 = new Type1();
Type2 t2 = new Type2();
String i1 = Image(t1);
String i2 = Image(t2);
When the first Image function is called, an unsatisfied link error will occur (and yes, in my actual code I did load the library containing the native function definitions and I have verified that the library contains and entry for each function as generated by javah). This is definitely a bug in how the VM generates the encoded signature for these function calls.
Should be very easy to fix I would think - hopefully soon, as this is stopping us from proceeding on a development right now :(
Thanks!
[1405 byte] By [
mjdalpeea] at [2007-11-26 12:46:46]

# 1
Wrong place to post this.
Wrong format as well.
You need to post a bug in the bug database.
http://bugs.sun.com/bugdatabase/index.jsp
You are stating that the function signature is wrong. So you need to post what signature is created and what signature is expected.
Do not expect a timely fix for this unless you have a significant account with Sun. If you do have such an account then you should talk to your Sun sales rep rather than technical support as this will produce a faster response.
Note that if the only problem is that javah is producing the wrong signature but the signatures are different then the immediate solution for you is to simply produce the signatures manually yourself.
> This is definitely a bug in how the VM generates
> the encoded signature for these function calls.
Emphasizing this again - you need to confirm that the bug is in the VM rather than javah.
# 2
Thanks very much for that info. I was wondering if there was a better place for this.
And yes, I verified it is a VM problem by building a debug version of the JDK and breaking in the call from the VM that attempts to resolve the name. javah correctly generates two different signatures for the overloaded function, but the VM is calling the resolve function with a name that omits the encoded function argument portion of the javah signature - that is, it looks to me like the VM is treating the signature generation for the overloaded function as if it were not overloaded.