JNI前面的工作都做完了，DLL也有了
我现在就做一个普通的web项目做测试，一个JSP页面，一个servlet，JSP调servlet，我先在servlet里写了个主方法,然后我直接运行主方法就OK，我一启动web在JSP页面上调servlet，在servlet里运行JNI的东西就报错说：java.lang.UnsatisfiedLinkError: no Code in java.library.pathCode是我要加载的一个类，里面有一句
static
{
System.loadLibrary("Code");
}
我现在就是在主方法里没问题，一到网站上用就不行
我现在就做一个普通的web项目做测试，一个JSP页面，一个servlet，JSP调servlet，我先在servlet里写了个主方法,然后我直接运行主方法就OK，我一启动web在JSP页面上调servlet，在servlet里运行JNI的东西就报错说：java.lang.UnsatisfiedLinkError: no Code in java.library.pathCode是我要加载的一个类，里面有一句
static
{
System.loadLibrary("Code");
}
我现在就是在主方法里没问题，一到网站上用就不行
java.library.path里面没有你的dll，你先用System.out.println(System.getProperties().get("java.library.path"));
输出看看，你的dll在不在下面的路径里。没有的话，就加进去，或者，调用时添加 -Djava.library.path= yourpath顺便给几条建议：1． 如果可以通过TCP/IP实现Java代码与本地C/C++代码的交互工作，那么最好不使用以上提到的JNI的方式，因为一次JNI调用非常耗时，大概要花0.5～1个毫秒。2． 在一个Applet应用中，不要使用JNI。因为在 applet 中可能引发安全异常。3． 将所有本地方法都封装在单个类中，这个类调用单个 DLL。对于每种目标操作系统，都可以用特定于适当平台的版本替换这个 DLL。这样就可以将本地代码的影响减至最小，并有助于将以后所需的移植问题包含在内。4． 本地方法要简单。尽量将生成的DLL 对任何第三方运行时 DLL 的依赖减到最小。使本地方法尽量独立，以将加载DLL 和应用程序所需的开销减到最小。如果必须要运行时 DLL，则应随应用程序一起提供它们。5． 本地代码运行时，没有有效地防数组越界错误、错误指针引用带来的间接错误等。所以必须保证保证本地代码的稳定性，因为，丝毫的错误都可能导致Java虚拟机崩溃。