目前在研究 BS 架构下面如何进行实现客户机的硬件调用问题.想到的方案为 JNI,JNLP 和 JS 调 ocx.各种方案具体如何实现以及最终如何选择,后续进展又是如何暂不在本博文的讨论行列.本文仅仅是说一下 java 环境变量的问题.
环境变量?大哥你确定你不是在逗我?随便一个 java 基础的人都会啊!万年的 java_home(额!这里一定得大写),classpath 和 path 呗!
确定不是逗你,如果你用的好死不死是 jdk1.8 的话,且听我慢慢道来.
问题描述
是这样,博主在探索 JNI 实现 BS 架构下的硬件调取的时候,发现了一个神奇的框架,叫做 JNA!使用该框架可以优雅快速的进行 java 调 C 的功能实现.没啥好说的,只要注意一个问题就行,关于 dll 的路径问题!千万注意,保证 dll 和 jdk 的版本一致性(即 32 位 jdk 调取 32 位 dll,64 位 jdk 调取 64 位 dll),存放位置嘛?博主建议将 dll 放在 jdk 的 bin 目录下即可.
言归正传,就是基于这个问题,出现了我对 jdk 环境变量的十分疑惑,起初让我懵逼的有点怀疑人生了!我拿到一个 32 位的 dll,然而我的 jdk 是 64 位,好死不死的 1.8.于是,我得换啊!
下载 32 位 jdk
安装
修改环境变量(额!当时用的 java_home,这里只要改一下这一个变量路径就好了,classpath 和 path 不用管了,引用的呗!不禁为自己的机智深深的鞠了一躬)
我信息慢慢的输入 java -version
神奇的事情发生了!what?竟然还是 64 位!
哥们起初还是相当淡定的.有啥大不了的事儿?资深码农哪有一帆风顺的代码?容哥慢慢检查一遍环境变量,将背后的黑手一把揪出来!(博主一直将注意了放在环境变量上面,于是乎,很悲剧!)
郁闷了半小时,百度一下,看看有没有同病相怜的病友吧!果然,一大堆!按照一下操作步骤顺利解决,惊恐的喝了一口鸡汤.这个世界变化太快,不改变永远没有未来.
解决方案
进入该文件夹 C:\ProgramData\Oracle\Java\javapath,会发现里面有三个 exe 文件,这三个 exe 文件引发的幺蛾子.把 32 位的 jdk 的 bin 目录对应的三个文件进行替换,之后 java -verion 就看到了久违的 32 位了.
来源: http://www.jianshu.com/p/09f723d37603