Java Native Access (JNA)承诺为Java和遗留代码之间搭建一座桥梁。为什么这点如此重要?首先, JNA避免了修改遗留代码,即便这些代码的改写要求是存在的。
同时,JNA意味着不再需要昂贵的私有的桥接解决方案。后者包括“神秘的史前工具”,就像是代理安 排、硬件编码专有协议等等。所有这些解决方案的趋势是很难预测的,易错以及具有潜在的脆弱因素。 JNA的另一个关键因素是能够有效的取代Java Native Interface (JNI)。
在这篇文章中,我所要探究的代码类型在这个列表一中将会让读者先睹为快。在列表一中,我引用来 自Windows kernel32 DLL 的GetTickCount()程序。自从系统启动,GetTickCount()返回所经过的毫秒的 个数。
public interface CLibrary extends Library {
CLibrary INSTANCE = (CLibrary)
Native.loadLibrary((Platform.isWindows() ? "kernel32" : "c"),
CLibrary.class);
int GetTickCount();
}
public static void main(String[] args) {
System.out.println("TickCount" + CLibrary.INSTANCE.GetTickCount());
}
列表一,简单的JNA实例
列表一中真正让人感兴趣的是JNI代码不再被需要。取而代之的是一种来自于Java代码的你可以简单的 称之为DLL的符号。映射和自动生成JNI头文件或者其他难以填满的材料都是不需要的。取代以上做法的是 ,伴随着JNA,简单的下载必须的库,标注兴趣符号,然后引用这些符号。
简而言之,JNA解决方案在任何体制下都可以节省费用。从Java径直访问遗留代码的能力可以排除任何 使用JNI或者改写遗留代码的需求。也许,JNA最好的承诺就是统一代码环境。无论如何,这里还有其它与 JNA有关的话题,这些话题都是关于入侵本机代码环境的。任何一个这样的话题都是围绕Java是否是所谓 的系统语言展开的。
Java:不是一种系统语言?
早期关于Java的一个重要的评论是说Java不是一种系统语言。不像C或者C++,Java生存在JVM内部,并 且不能存取低级别的,机器方面的细节问题。允许这些操作的地方,都是需要经过高级别的API。JVM中孤 立Java的一个关键功能就是保证安全——JVM可能会崩溃,但是它不会致使整个系统瘫痪。
JNA的出现正在潜移默化的改变这些,因为现在Java代码可以存取C风格的结构。列表二显示了Java代 码在Windows kernel32 DLL中通过函数存取数据的另一个例子。
Kernel32 lib = Kernel32.INSTANCE;
SYSTEMTIME time = new SYSTEMTIME();
lib.GetSystemTime(time);
System.out.println("Today's integer value is " + time.wDay);
列表2,kernel32.dll系统时间
列表二中,注意到Java代码有权使用低级别的平台数据。JNI意味着Java具有可以存取系统级别数据的 能力。无论如何,JNA的另一个重要的应用是遗留代码存取,这些遗留代码中存在大量的有商业价值的信 息;举例来说,书写在C/C++中的复杂的数学函数。现在,与其使用JNI,有可能的话还不如直接引用JNA遗 留的函数。换句话说,JNA可以被认为是一种桥接技术。