|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 6
However, developing software with MFC is not an easy task. In order to write today's Windows applications using C++ and MFC, developers need to have a good understanding of object-oriented programming concepts, C++ syntax and peculiarities, the Windows APIs, and MFC.
Ideally, developers need a single language and platform that allows them to write applications just once and then deploy them everywhere. In an attempt to meet this need, Sun has implemented platform-neutral versions of many Windows APIs in addition to APIs unique to Java (such as Java Card). APIs dealing with file management, mail, help, multimedia, and security have counterparts in the Windows world. This results in one major benefit to Windows developers: Instead of learning a lot of Windows APIs along with C++ and MFC, developers can focus on learning Java and its APIs. Then, they can use Java to develop Windows applications. Here's how.
The designers of Java came up with a mechanism for getting Java code to talk to C++ code. This mechanism uses a collection of C++ APIs known as the Java Native Interface (JNI). Several of these APIs have been brought together, and are collectively known as the Invocation API.
The Invocation API consists of several JNI functions that enable the developer to embed the Java virtual machine (JVM) into an arbitrary native application. With JVM embedded, the native application has access to the entire JVM by making JNI calls.
The JVM is created via a call to the JNI_CreateJavaVM () function. This function takes a pointer to a JDK1_1InitArgs structure as an argument. This structure provides default settings for the JVM. The defaults can be overridden.
To obtain the default settings, another JNI function, JNI_GetDefaultJavaVMInitArgs (), must be called. This function takes a pointer to the JDK1_1InitArgs structure as an argument. A typical calling sequence appears in the following listing:
JDK1_1InitArgs vm_args; vm_args.version = 0x00010001; JNI_GetDefaultJavaVMInitArgs (&vm_args);
The version field must be set prior to calling JNI_GetDefaultJavaVMInitArgs (). This field ensures that the correct JVM is used by the application. A value of 0x00010001 encodes the major version number
of the required JVM in the high 16 bits and the minor version number in the low 16 bits. The 0x00010001 value means that any
JVM whose version number is 1.1.2 or higher will be embedded into the application.
Several interesting fields comprise the JDK1_1InitArgs structure, but the only field we'll mention in this article is the field known as classpath. This field is important because it tells the JVM where classes.zip and the application class files reside.
Once the JDK1_1InitArgs structure has been initialized, the JVM can be created via a call to JNI_CreateJavaVM (), as shown in the following listing:
JavaVM *jvm; JNIEnv *env; rc = JNI_CreateJavaVM (&jvm, &env, &vm_args);
At this point, JNI functions FindClass () and CallStaticVoidMethod () would be called to find the appropriate Java starting class and the starting main method.