<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 2, 2013, at 7:32 PM, Vladimir Kozlov &lt;<a href="mailto:vladimir.kozlov@oracle.com">vladimir.kozlov@oracle.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">The exception is then caught and forwarded on the return from lookup() call and before the call to a native function.</span><br style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "></blockquote></div><br><div>Here are some interesting points of JVM trivia which relates to the unusual control flow in this code:</div><div><br></div><div>JVMS 5.4.3 says, "If an attempt by the Java virtual machine to resolve a symbolic reference fails&nbsp;because an error is thrown that is an instance of&nbsp;LinkageError&nbsp;(or a subclass), then&nbsp;subsequent attempts to&nbsp;resolve the reference always fail with the same error that&nbsp;was thrown as a result of the initial resolution attempt."</div><div><br></div><div>In other words, for each symbolic reference you get just one chance to resolve it successfully. &nbsp;If it fails to resolve, you throw the same error every time in the future. &nbsp;(This means you need a failure record somewhere in the JVM.)</div><div><br></div><div>Since UnsatisfiedLinkError is a subclass of LinkageError, you might think this rule applies. &nbsp;But it doesn't. &nbsp;When you resolve a native call site, you succeed if you get access to the Java side of the native method. &nbsp;A subsequent operation, at runtime not link time, determines whether the call into native code succeeds.</div><div><br></div><div>The JVMS says this for the invoke instructions, under Runtime Exceptions (not Linking Exceptions): &nbsp;"Otherwise, if the selected method is native and the code that implements the method cannot be bound, invokespecial throws an UnsatisfiedLinkError." &nbsp;The placement of this language implies that the&nbsp;UnsatisfiedLinkError&nbsp;can be repeated. &nbsp;It can even go away, if somebody does a System.loadLibrary call that happens to supply the right native entry point (or so I think). &nbsp;JNI supplies a way to unload native methods also, so a bound native method can apparently change state between ULE-throwing and normal function any number of times.</div><div><br></div><div>In any case, this is why there is a funny extra degree of freedom, and an extra binding pass, in the JVM for the native function binding of a Java native method.</div><div><br></div><div> John</div></body></html>