While Microsoft's support for Java seems to range from lukewarm to non-existent, it continues to make available the Microsoft SDK for Java 4.0 for download. It includes two application launchers, jview.exe and wjview.exe. They operate like java.exe and javaw.exe, although command-line syntax differs substantially. The Java virtual machine included in the package reports its java.version property as 1.1.4. Version 3.2.2 of jEdit will run in Microsoft's virtual machine if you place the Swing classes in its classpath.

It's not a good idea to try importing the Swing classes from a recent JDK version. Sun offers a download of Swing 1.1.1 (also known as JFC/Swing 1.1.1) that seems to work well. The downloaded Swing archive is named swing1_1_1.zip. Extract the swingall.jar file from the archive and copy it the directory in which jEdit is installed (so it shares the same directory as jedit.jar).

One more step is necessary. The Microsoft application loaders apparently read the contents of the CLASSPATH variable into its classpath even if you specify a classpath on the command line. You need to undefine that variable temporarily to prevent all kinds of linkage errors from mixing classes from vastly different JDK versions.

The following batch file should get jEdit running under the Microsoft virtual machine. Note that some lines of code are truncated and spread over two lines because of the width of this article's display. The file is available in the Downloads section.

@echo off
REM Windows batch file for running jEdit 3.2.2 in
REM the Microsoft VM
REM Author: John Gellene (jgellene@nyc.rr.com)
REM Placed in the public domain.

REM Define JEDIT_MSVMDIR as the folder in
REM which jedit.jar and swingall.jar from Sun's
REM Swing 1.1.1 distribution are located.
REM Define MSVMPATH as the full path to the
REM application loader.

SET JEDIT_MSDRIVE=C:
SET JEDIT_MSDIR="C:\Program Files\jEdit"
SET MSVMPATH="C:\Program Files\Microsoft SDK for Java 4.0\bin\jview.exe"

REM Now undefine and save the CLASSPATH
REM variable if it exists.

SET OLD_CLASSPATH=%CLASSPATH%
SET CLASSPATH=

REM The next line makes sure you are in the
REM correct drive

%JEDIT_MSDRIVE%

REM Now run jEdit and restore the value of
REM CLASSPATH when completed. We will use
REM the full path to the application loader.

REM If you use jview.exe, you will get error
REM output written to a console window. This is
REM a good idea until you got the VM working
REM consistently in case the process hangs.

REM Any command line options for jEdit can
REM follow the main class name.

CD %JEDIT_MSDIR%
%MSVMPATH% -cp jedit.jar -cp swingall.jar org.gjt.sp.jedit.jEdit

REM The session is over. Clean up the
REM environment.

SET MSVMPATH=
SET MSJEDIT_DIR=
SET CLASSPATH=%OLD_CLASSPATH%
SET OLD_CLASSPATH=

REM End of batch file.

This batch file gets jEdit up and running in about five seconds on a 600MHz Pentium III desktop running Windows 2000, even with about twenty plugins loaded. The responsiveness of the program is indistinguishable from native, non-Java applications. After using jEdit for about a year with the Sun JDK, I was stunned by the difference in performance speed. The GUI is also more compact, even compared with the improvements found in Sun's beta versions of JDK 1.4. Text rendering with the AWT package actually appears sharper than the display drawn by the Java 2D routines used on later JDK versions. There is also less leading betwen lines in the text area, so you get more lines of text displayed without undue crowding.

You do lose a few things, however, and they are not trivial. There is no support for a wheel mouse or drag and drop. A number of plugins require later JDK versions and are not available from Plugin Central. There are a few features in BeanShell, the Console plugin and elsewhere that are not available because they require the Reflection API in JDK 1.3. After a macro's message box is dismissed, input focus does not return to the text area (although this can be fixed with a BeanShell call to textArea.requestFocus()). Finally, if you are compiling Java programs within the VM in which jEdit is running, you are limited to its runtime tool classes.

The next version of jEdit, version 4.0, will not run on version 1.1 of the JDK, so the Microsoft VM option will not be avalable in the future. For the present, I think a number of Windows users may find the choice between virtual machines a hard one to make. It's a shame the software wars require them to make it.