目前在研究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位了。
