windows 64位机器上的java，调用native方法，可否用32位的dll？

64bit java native方法 dll

解决方案 »

  1.   

    直接用应该是不行的，可以考虑另启一个32位JVM，通过RMI访问。
      

  2.   

    64位的系统，理论上，用32位的dll之类的，一般是能够兼容的
    反之就肯定不行了，32位的系统，用64位的dll之类的，肯定不行。
      

  3.   

    我认为是没有问题的。
    jni进行函数调用，将java参数转换为C时，不论64位的java虚拟机还是32位的，这个过程都是一样的。在java里面，long，int之类数据的字长总是固定的。
    你的这个问题的关键在于，你的32位dll在64位操作系统下能不能跑。只要这个dll能够在64位机上跑，Java就能调用到。
      

  4.   

    机器是64位没关系， jre/jdk是32位的，就可以调32位DLL。
      

  5.   

    我试过在64位电脑上调用32位的DLL，行不通，
      

  6.   

    这个目前无解。
    JNI只能是32位JDK对应32位DLL；64位JDK对应64位DLL。不过楼上说的，再部署一个32位的JDK，RMI调用也是个权宜之计。
      

  7.   

    Lz,我的是windows7的64位系统，Java jdk是64位的，用的是vs2010，jni运行后出现不能加载IA32位的dll到AMD64位的平台，网上说把vs2010的编译平台换成x64,编译后就是64位的dll,这样还是不行，请问有什么解决办法，不想安装32位的Java jdk
      

  8.   

    应该是不行的，我们也正在测试。目标dll是32位的，开发环境是64位的，jdk是64位的，开发环境默认使用32位编译出来的dll，给64位jdk调用，出现错误，如15楼所说的。开发环境改为64位编译，不导入目标dll是可以编译成功，也可以被64为jdk调用，15楼的盆友应该是没编译对吧，有一点注意的是，编译完后目录会改变的，一个x64的debug目录。如果开发环境导入目标dll，然后编译为64为dll，直接连接报错~ 
      

  9.   

    我也遇到了类似的问题，我现在要用GNU 的gsl做一些dll共java调用，测试时能够成功生成32位的dll，生成64位的dll不成功，调用dll的java环境是64位的。我编译的具体情况可以在百度知道里面的提问：http://zhidao.baidu.com/question/809120831325765732.html?quesup2&oldq=1，不知道能否帮忙解答下。