s a Java support engineer at Microsoft, I field a lot of questions about all aspects of the Java language and Visual J++™. I rarely hear the three words that can make the medicine go down: "software development kit." Just last week I was completing some training, and my instructor—a very bright individual who happens to teach Java as well—was grilling me on some of the new packaging and deployment options offered by Microsoft. After a few hurried explanations, as he scribbled notes on the whiteboard, I said, "You know, all this stuff is in the SDK." Anyway, I was somewhat surprised that he wasn't familiar with the Microsoft® Software Development Kit for Java. With all the media attention and fanfare that Visual J++ 6.0 has been getting, you'd think more people would also have heard of the SDK for Java.
      What is the SDK for Java that Visual J++ is not? Well, the SDK is redistributable for one, although you need to read the End User License Agreement (EULA) and the documentation to see exactly what is redistributable and what is not. For instance, you can't ship the compiler. The distributable components are listed at http://www.microsoft.com/Java/sdk/40/start.htm.
      Although the SDK is free, you have to remember that it's a kit, not an environment. Being a kit means that it provides command-line tools and batch files, whereas an environment suggests a rich set of tools that exist behind a visually pleasing GUI. If you want an environment, look at Visual J++ 6.0, which follows the Visual Basic® design philosophy. While there are undoubtedly a number of readers who will appreciate the raw console nature of the SDK, the main attraction is in the quick turnover of new versions and bleeding-edge builds.
      Many of the tools found in the SDK are also shipped with Visual J++, including the compiler (jvc.exe, msjvc.dll, and jps.dll), the interpreter (jview.exe or wjview.exe), the Microsoft virtual machine (msjava.dll), and the code-signing and deployment tools (signcode.exe and dubuild.exe).
      By plugging in the latest builds of these tools, you can easily upgrade the Visual J++ environment. When you install the SDK, the latest build of the virtual machine (VM) installs automatically. To upgrade the compiler, you need to copy those three files to the SharedIDE\Bin directory of your Developer Studio® installation. (The Visual J++ 6.0 installation defaults to the Microsoft Visual Studio\Vj98 directory.) If you have Visual J++ 1.1 or earlier, you need to upgrade the compiler in this fashion to get Java 1.1 language features such as inner classes and the newer APIs.
      The Knowledge Base article titled "Historical List of Shipping Vehicles for the Microsoft Virtual Machine" (Q169803) lists the different builds that have shipped with the various Microsoft Java-related products and their corresponding JDK compatibility versions. You can search for this article or any Knowledge Base article from http://support.microsoft.com/support.
      Jview.exe and wjview.exe are the Microsoft interpreters for Java. These are the programs that drive the Microsoft VM, which is, you guessed it, a COM object. Jview.exe is placed in the Windows or WinNT folder; by typing jview from the command line, you can find the version of the Microsoft VM. wjview is very similar to jview, but it doesn't support console output and is intended for GUI-based programs. The core component of the Microsoft VM is a file called msjava.dll. Its version reporting will reflect the VM build as well. Visual J++, Microsoft Internet Explorer, and the SDK for Java install the Microsoft VM for Java by default.
      You can download the latest version of the VM from http://www.microsoft.com/java/vm/dl_vm31.htm, and you can get the debug classes as well. The Microsoft Knowledge Base article "Automatically Update the Microsoft VM for Java" (Q163638) shows how you can ensure that your customers have the latest build of the Microsoft VM as well.
      Almost everything in the help system is now created using HTML. The online documentation you get with version 3.1 of the SDK will work with both HTML help and the Visual J++ 6.0 help system (in the form of .chm files). Before this release, SDK documentation was solely in HTML, so it couldn't be integrated into the context-sensitive help system of Visual J++ 1.1.
      The InfoViewer in Visual J++ 1.1 is like a minibrowser. If you drag and drop a shortcut or link to the default.htm page of the Java SDK documentation (or any HTML-based documentation), you can view the pages, set bookmarks, and add it to the favorites list of Internet Explorer. In this way, you can browse the online documentation from within the Visual J++ 1.1 IDE while the document pages reside on the local hard drive. And since HTML is merely a collection of delimited tags in a text file, you can use traditional text searching tools to find information in these files. Try Edit | Find In Files from the menu in Visual J++ 1.1 to search the directories of an HTML-based documentation install. (As you know, HTML files on a Windows® platform almost always have the .htm or .html extension.)
      A little-known utility I haven't mentioned yet comes only with the SDK: it's called clspack.exe, or the class pack utility. This utility fixes a lot of classpath-related install issues. You may have heard of the Java Package Manager (JPM), which was introduced in Internet Explorer 4.0. But not all Java products use the JPM. Some products, like Visual J++ 1.1, still need the old classes.exe file found under %windir%\java\ classes. The class pack utility extracts the packages of Java classes from the package manager and builds a classes.zip file for these older programs that use the traditional classpath environment variable.
      The Microsoft VM now uses registry entries to store some default classpath values. You can change or add to these default classpaths either through an environment variable or by altering the registry key. Visual J++ 1.1 also allows you to set additional classpath directories through the Project Settings | General menu choice. Keep in mind that the clspack utility won't help the programs that need classes.zip if the value of the ClassPath key is not properly set. You can fire up Regedit and look under the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Java VM key if you are having classpath problems. A typical value for the Classpath key is C:\ WINNT\java\classes\classes.zip;C:\WINNT\java\lib\bob.zip;. Most values will also include the Classes folder, but I removed it manually from my system and added my own packages found in bob.zip. Also, notice the period following the last entry. A period stands for the working directory; using it includes the working directory in the classpath.
      The package manager mangles .zip file names to avoid potential namespace conflicts, then stores the files in the C:\Windows\Java\Packages folder. The proper names of the various packages can be found in the C:\WINNT\Downloaded Program Files folder. Try right-clicking on one of these and see what happens. Be careful not to remove something important! The Knowledge Base article "How Does the Java Virtual Machine Search for Java Classes?" (Q177168) explains when and how the Microsoft VM searches for Java classes in and around the package manager.
      The tools in the Microsoft SDK evolve somewhat independently of the Visual J++ IDE, as evidenced by the merger of javatlb.exe and jcom.exe into jactivex.exe. As the online documentation says, "The jactivex utility is used for hosting automation-enabled ActiveX® controls in Java, and generating .java files for the classes and interfaces that are described by a type library. These .java files, once compiled into .class files, allow Java programs to use COM (Component Object Model) services. Although the default operation of the tool is ActiveX control manipulation in Java, this documentation only covers tool usage for features originally supported by the javatlb and jcom tools (which this tool replaces)." Long before Visual J++ 6.0 (which automates much of the process) came along, the SDK for Java was defining how Java-COM integration was to be performed.
      In addition to bleeding-edge builds for the tools, compiler, and VM, new Microsoft Java-related technologies and libraries will usually surface first in the SDK for Java. The Windows Foundation Classes (WFC), one of this year's hot Java topics, and now part of the SDK, and the technology upon which they are based first surfaced there. This base technology, called J/Direct™, allows Java developers to call directly into the Windows APIs, or to any function exported from a DLL. WFC wraps the Windows API functions and uses J/Direct as its calling mechanism. And it all started in the Software Development Kit for Java.