Getting Small: The Windows CE Toolkit for Visual J++

By Raj Pai

You know how to use Visual J++ (VJ++). Now you can write portable applications for handheld devices. While the Sun hype-machine has been trumpeting the arrival of "devices" like the Java ring, Microsoft has quietly been the first to provide real developer tools targeting real devices running the Windows CE operating system. Joining Visual Basic and Visual C++, VJ++ now has a Windows CE Toolkit that makes it as easy to write VJ++ applications for Windows CE as it is for Win32.

With the release of the Java VM for Windows CE and the Windows CE Toolkit for Visual J++, Microsoft has acquired the lead in the Java handheld device and developer tools market. To begin developing powerful VJ++ applications for Windows CE, you only need to pick up a copy of the Microsoft Windows CE Toolkit for Visual J++ at your local software retailer.

Overview

When Microsoft established its overall Java strategy in 1996, they had three goals in mind: to make Windows the best execution platform for Java; to create the best development tool for Java; and to enable Java developers to build great Windows applications. In applying its Java strategy to Windows CE, Microsoft has remained consistent with these three goals. So, now you can fit the power of the Java language and the richness of the Windows API into your pocket.

The key to making Windows CE the best execution platform for Java lies in Microsoft's implementation of the Java VM for Windows CE. The Java VM is JDK 1.1.3-compliant, and fully supports the JDK 1.1 event model. To minimize the footprint on the device, the VM is a fraction of the size of the desktop VM — less than 4MB as opposed to over 12MB. The following is the subset of standard libraries included in the VM:

java.applet (no appletviewer or pIE support exists for the java.applet class.)

java.awt

java.beans

java.io

java.lang

java.math

java.net

java.security

java.sql (requires ODBC support, which can be obtained from third-party ISVs.)

java.text

java.util

The VM supports a feature called Execute In Place (XIP), so when installed on a ROM, the time and memory hit to load classes into RAM before executing them is eliminated. (Custom installations of the VM on ROM can be created by system integrators using the Microsoft Embedded Toolkit.) The VM is also installable in RAM, although this is impractical for devices with less than 16MB of memory.

To increase performance, there are native method DLLs for all of the Java packages. If the target device will only run applications built by one vendor, the cls2pe utility can be used to create a custom core class DLL that includes only the Java class library classes required by that vendor's applications, in addition to the application classes themselves.

The relatively small memory footprint of the Java VM, combined with XIP and native method DLLs, allows you to deliver high performance in a resource-constrained environment.

The second goal in Microsoft's Java strategy was to create the best development tool for Java. Because the Toolkit is an add-in to Visual J++ 1.1, Microsoft succeeds in this point by leveraging the power of the most widely used Java development tool in the market.

Developing and debugging an application targeted at Windows CE is an identical experience to developing and debugging a desktop application. It uses the same compiler and the same class file format. All major debugging functionality, including breakpoints, single-stepping, and examining and watching variables, is supported in both emulation debugging and in remote device debugging.

Creating a new application for Windows CE is a snap. There is a Windows CE Application Wizard that can be launched from the New Project window, which will generate sample code supporting multithreading, animation, and mouse event handlers. Currently, the wizard generates JDK 1.0.2-compatible code, but an upcoming service pack will upgrade the wizard to generate JDK 1.1-compatible code. You can choose to build to the emulator, or auto-download and execute/debug on the device.

The third objective in Microsoft's Java strategy is to enable Java developers to build great Windows applications. Raw Native Interface (RNI) is one key to enabling this. RNI enables application developers to access the full power of the Windows CE platform API when used in conjunction with Visual C++. It can be used to take advantage of native device capabilities, such as the infrared port.

The current incarnation of the VM doesn't have ActiveX/COM interoperability, J/Direct support, or WFC support. These technologies will likely be included in an upcoming release of the VM and Toolkit. Currently, there is no applet support, but upcoming releases will allow applets to run within jview when the applet switch is on. See Figure 1 for a list of supported features.

Figure 1: Supported features of the Windows CE Toolkit (* indicates that Windows NT 4.0 is required).

Requirements

Like the Windows CE Toolkit for Visual Basic, the Toolkit for Visual J++ targets only Handheld PCs (H/PC) running Windows CE 2.0 or greater. It supports all H/PC processors (MIPS 39xx, MIPS 41xx, Sp).

The memory footprint required by the Java VM (as much as 4MB), makes it impractical to develop for devices with less then 8MB of RAM. Compact devices, such as the Palm-Size PC and Auto PC, don't currently support the Java VM. As more machines are built with the VM on a ROM, these memory constraints may become less of an issue, but for now, 16MB of RAM is required to do remote debugging on the device, and this memory size is recommended to run Java applications.

Because the Toolkit is simply an add-in to Visual J++ 1.1, there aren't any additional requirements on the desktop side — only a couple of notable exceptions. The Windows CE emulation environment (included with the Toolkit) runs only on Windows NT 4.0, so if you wish to run your application in emulation, you must install Windows NT. Windows NT is also required for some of the remote tools.

The Toolkit uses the version of the jvc.exe compiler found in the Microsoft SDK 2.0 for Java. While this compiler is included with the Toolkit and is used when building to Windows CE, it doesn't, by default, replace the version of jvc.exe used for desktop compilation. Unless you install the SDK, building to the desktop will still use the old compiler. See Figure 2 for a table of requirements.

Figure 2: Requirements for the Windows CE Toolkit.

A Quick Run-through

Installation of the Toolkit is straightforward. If you haven't already installed Windows CE Services 2.0, or the Windows CE Platform SDK (which includes the emulation environment and remote tools), they are installed as part of the Toolkit setup program.

To create a new Java application for Windows CE, simply select WCE Java Application Wizard from the Project page of Visual Studio's New dialog box (see Figure 3). From the right-hand side of the screen, you can select which platforms you want to target: the remote device, the emulator, or both.

Figure 3: The Projects page of the New dialog box.

The emulator occupies the upper-left corner of your screen, and runs and looks exactly like a color H/PC. Figure 4 shows the emulator running on the desktop, and Figure 5 shows the actual display on an H/PC. The emulator is automatically launched when an application that targets it is executed or debugged.

Figure 4: The emulation environment on a Windows NT 4.0 system (upper-left corner).

Figure 5: A Windows CE-based device.

On the wizard's first screen, you'll see the familiar VJ++ project wizard that asks you to name the main class for the project, and gives you the option of generating source-file comments (see Figure 6).

Figure 6: Step 1 of the WCE Java Application Wizard.

The second screen of the wizard allows you to add multithreading and/or animation sample code to your new project. It also will generate the stubs for the mouse event handlers that you would like to include in your application (see Figure 7).

Figure 7: Step 2 of the WCE Java Application Wizard.

The final screen shows a summary of the choices you have made so far. When you hit the OK button, you return to the IDE where you can begin coding your application using the framework the Toolkit has built for you.

When it's time to debug or execute your application, you can choose to target the emulator or the remote device. The easiest way to make this selection is to add the full Build bar to your toolboxes (not the Build MiniBar). The Build bar has a combo box that allows you to select whether you want to target the device or the emulator (see Figure 8).

Figure 8: The Build bar.

Now simply compile your project, and execute or debug just as you would a desktop application. The Toolkit takes care of downloading the class files — either to the object store used by the emulator, or to the remote device. Figure 9 shows the debugger in action.

Figure 9: The debugger in action in emulation.

Design Issues

Like all things that sound too good to be true, the "write once, run everywhere" mantra stumbles a bit when applied to a real application. While it's easy to port desktop applications to a Windows CE-based device, the result may not be exactly what you expect. User interfaces that are not custom developed for Windows CE will rarely look the same on a device as they do on the desktop.

The main reason for this is the form factor of the device. The standard resolution on an H/PC is 480x240 (versus the 800x600 or 1024x768 on most desktops). Most forms are designed to cover the larger screen area of a desktop, and will run off the screen on a Windows CE-based device. While AWT layouts can ensure that the form will fit on the screen, layouts do not ensure the resulting form will be usable in its stretched and shrunken state.

Speaking of stretching forms, when Java becomes available on the Palm-Size PC, the UI must be developed with a portrait orientation in mind. This — plus the lack of a real keyboard on the device — will make the desired UI for the Palm-Size PC substantially different than the UI on an H/PC.

Many H/PCs only support black and white or gray-scale displays, so a UI that looks good in color may be unreadable on the handheld device. Care must be taken to design UIs for the lowest-common-denominator machine for which you are developing.

It's also important to keep in mind that the windowing paradigm of Windows CE is slightly different than on Win32. Windows CE does not support MDI, or sizeable windows. Any UI you have that relies on these features must be modified to run on the Windows CE-based device.

The full desktop run-time library takes up 12MB, but the complete subset fits on 4MB on an H/PC. Make sure your applications don't use classes outside the standard subset (again, see the subset of standard libraries shown earlier in this article).

Conclusion

The Windows CE Toolkit for Visual J++ is the best solution for programming handheld devices in Java. The Java VM implementation offers a high-performance execution environment that fits in a minimal footprint on the device. The Toolkit seamlessly integrates with VJ++, thus making it almost trivial to begin writing applications for H/PCs. All the development and debugger features of VJ++ can be used when targeting Windows CE, in both the emulation environment, and on the remote device. Using RNI, it's possible to access all the functionality of the Windows CE APIs from within your Java applications.

With Windows CE, Microsoft has made a firm commitment to providing a compelling subset of Win32 functionality. Moving into the future, this means that technologies currently only on the desktop side will be making their way onto Windows CE-based devices. Work is already in progress to build new toolkits to support the release of Visual Studio 98 (including Visual J++ 6.0), and a service pack for the current VJ++ Toolkit is close to completion.

Windows CE is here to stay, and Microsoft is diligently working to make sure developer Toolkits leverage all the capabilities of devices powered by Windows CE, without overly complicating the development experience.

Raj Pai is a Program Manager Intern in the Microsoft Visual J++ product group. He currently attends Stanford University and can be reached at Pai_r@hotmail.com. The views expressed in this article do not necessarily reflect the views of Microsoft.