Applets run via browser plug-in from the local file-system (file:///) are subject to almost exactly the same security checks as applets loaded from the web. The difference being that applets loaded from the web have the permission to "call home", ie. connect back to the server the applet originated from, and applets loaded from the filesystem have the permission to access the files in the same folder.
The sandbox by default does not permit loading native libraries in either case.
You could consider signing the applet. The user will have to OK the security dialog. And unless you have a code-signing certificate purchased from a certificate authority the dialog will warn the user of the fact that it's not signed by a trusted party.
I didn't fully understand your use-case, but if you can run other code on the local machine, you could always alter the java security policy in order to trust a .jar file in some specific local location. This way no security dialog gets presented.
To do this, you alter the java policy file, which on a windows machine with Java 6 would probably be in:
%PROGRAM FILES%Javajre6libsecurityjava.policy
And add a new permission, something like this:
grant codeBase "file:///path/yourcomponent.jar" {
permission java.lang.RuntimePermission "loadLibrary.jzmq";
};
EDIT: To give full permissions, you could add a permission like this (this is copied from a succesful test I did just now):
grant codeBase "file:///C:/component/policytest.jar" {
permission java.security.AllPermission;
};
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…