The Win32-Java hybrid

While you’re waiting for Microsoft to reveal its future strategy for Java on various Windows platforms (if there is one), you can take advantage of a Windows application development solution that blends Win32 and Java technologies into a single, cohesive unit. This Win32-Java hybrid (WJH) solution makes it possible to quickly create interesting and robust Windows applications, such as a smart card-based security system.

Win32 is Microsoft’s architecture for its 32-bit operating systems. Win32 includes a collection of APIs (application programming interfaces) that Windows applications can call during their execution lifetimes. These applications are written in languages such as C, C++, or Visual Basic, and then compiled into executable code which is stored in DLL or EXE files.

The structure of a WJH application is illustrated in Figure 1.

The red arrows indicate the composition of a WJH application — a Win32 executable and at least one Java class file. The Win32 executable, among other things, loads the Java virtual machine (JVM) DLL and creates an instance of the virtual machine. The starting Java class file and its main method are identified. This information and its associated command-line arguments are passed to the JVM. The JVM then loads this class file and interprets the instructions located in the file. To assist it in carrying out these instructions, the JVM may call Win32 API functionality or JVM Win32 DLLs that support the JVM.

The idea behind the WJH is to write a small amount of code in C or C++ (the Win32 JVM launcher) and to write most of the code (the application portion) in Java. So what is to be gained by using the WJH approach over the more conventional Win32, C/C++, or Visual Basic approaches? Table 1 lists some advantages.

For all its advantages, Java has one significant disadvantage — performance. Virtual machines slow performance. However, the advent of the just-in-time compiler (that part of the JVM which compiles Java instructions — known as bytecode — into native machine instructions during execution) is fast causing the performance issue to disappear.

So, how do we create a WJH application? The best way to answer that question is to study an example. To that end, I’m presenting a text editor application that is partly written in C (I didn’t need C++ for this application) and mostly written in Java.

The text editor application is called te. The Java section of the program was built using JDK 1.2. The C portion was built using Borland C++ 4.52. (Yes, you can write meaningful WJH applications using a non-Visual C++ development tool.)

Table 2 identifies the source and executable files that constitute the Java section of the program. These files are distributed in an archive called te-java.zip. To download these sample code files, click here.

Table 3 identifies the source and executable files that constitute the C portion of the WJH. These files are distributed in an archive called te-c.zip. To download these sample code files, click here.

If you want to learn how te works, first study te.c (the source for te.exe) and then te.java (the source for te.class).

For the purposes of this article, it isn’t necessary to go through all of te.c, since it contains a generous helping of comments. However, there are a few observations worth noting.

As you probably know, there are two kinds of Windows applications: console-based and GUI (graphical user interface)-based. This example utilizes a console-based format for te.exe; however, it doesn’t matter whether or not you choose console or GUI as your compiler option when creating WJH applications, because the Win32 part of the app wouldn’t normally register window classes, create windows, or contain messaging loops.

In the example, we disabled Ctrl-Break key presses so that they won’t disrupt te. You can do this by calling the Win32 SetConsoleCtrlHandler API. Without this call, the JVM could abort while executing Java instructions and remaining code in the Win32 executable wouldn’t be reached. Do you have to disable Ctrl-Breaks? That depends upon your application, but it’s always better to play it safe.

The LoadJVM function (in te.c) queries the Windows registry for the location and name of the JVM DLL. This information is located in a subkey of the HKEY_LOCAL_MACHINE root key. This subkey is SOFTWAREJavaSoftJava Runtime Environment1.2 and contains a RuntimeLib entry. The value associated with this entry is the location and name of the JVM DLL.

Finally, let’s examine te.java. Figure 2 shows te‘s main window.

This window consists of a single File menu (with Load, Save, and Quit options), a text area for viewing and editing the contents of a file, and a pair of status lines (one line identifies currently loaded or saved file while the other line displays error messages).

Before concluding, let’s summarize what you need to do in order to run the text editor on your computer.

• Install the JRE
• Place te.exe and te.class in the same directory
• Set the CLASSPATH environment variable (a Win32 environment variable that the JVM uses to locate class files) to point to the directory containing te.class

if (RegOpenKeyEx (HKEY_LOCAL_MACHINE,
                  "SOFTWAREJavaSoftJava Runtime Environment1.4",
                  0,
                  KEY_ALL_ACCESS,
                  &key) != ERROR_SUCCESS)

While the Win32-Java hybrid approach won’t be useful in all situations, it’s a good little hack to keep your Java skills relevant and your Java code running in a Windows environment. With a little practice, this alternative method can become a valuable tactic for getting through the turbulence that now has the Java community rattled with uncertainty.