Use JNA to protect your legacy code (i)

Java Native Access (JNA) promises to build a bridge between Java and Legacy code. Why is this so important? First, JNA avoids modifying legacy code, even if the rewrite requirements for those codes exist.

At the same time, JNA means that expensive private bridging solutions are no longer needed. The latter includes "mysterious prehistoric tools", such as proxy arrangements, hardware-coded proprietary protocols, and so on. Trends in all of these solutions are difficult to predict, error-prone, and potentially vulnerable factors. Another key element of JNA is the ability to effectively replace the Java Native Interface (JNI).

In this article, the type of code I'm going to explore in this list will give the reader a sneak peek. In list one, I refer to the GetTickCount () program from the Windows Kernel32 DLL. GetTickCount () returns the number of milliseconds that have elapsed since the system started.

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());
　　}

List one, simple JNA instance

What's really interesting in list one is that JNI code is no longer needed. Instead, it's a symbol from Java code that you can simply call a DLL. Mapping and automatically generating JNI header files or other materials that are difficult to fill are unnecessary. Instead, with the JNA, simply download the necessary libraries, mark the interest symbols, and then reference the symbols.

In short, JNA solutions can save money under any system. The ability to directly access legacy code from Java can eliminate any need to use JNI or overwrite legacy code. Perhaps the best promise of JNA is the unified code environment. Anyway, there are other topics related to JNA, all of which are about intrusion into native code environments. Any such topic revolves around whether Java is the so-called system language.

Java: Not a system language?

An important early comment about Java is that Java is not a system language. Unlike C or C++,java living within the JVM, and not accessing low-level, machine-specific details. Where these operations are allowed, there is a high level of API required. A key function of isolating Java in the JVM is to ensure that the security--JVM may crash, but it does not paralyse the entire system.

The advent of JNA is subtly changing these, as Java code now has access to C-style architecture. Listing II shows another example of Java code accessing data through functions in a Windows KERNEL32 DLL.

Kernel32 lib = Kernel32.INSTANCE;
　　SYSTEMTIME time = new SYSTEMTIME();
　 　lib.GetSystemTime(time);
　　System.out.println("Today's integer value is " + time.wDay);

List 2,kernel32.dll system time

In list two, note that Java code has permission to use low-level platform data. JNI means that Java has the ability to access system-level data. In any case, another important application of JNA is the legacy code access, which contains a large amount of commercially valuable information, for example, a complex mathematical function written in C/S. Now, rather than using JNI, it is possible to refer directly to JNA legacy functions. In other words, JNA can be considered a bridging technique.