Java is a hugely popular programming language with millions of programmers worldwide. It has a lot of advantages over traditional programming languages like C or C++ and some ever over C# (even when the latter has certainly eliminated some of Java's shortcomings and is definitely better for developing programs targeted at a specific platform like the Pocket PC). Sun has made a major mistake when they stopped developing (please read this thread on this subject) its free PersonalJava implementation. Furthermore, Microsoft has never provided any JVM (Java Virtual Machine; the environment to run Java programs) for the Pocket PC platform either. This means we have to rely on third-party JVM's to run our Java programs on. Fortunately, especially with some degree of hacking, these third-party JVM's are much more powerful and versatile than you would think. What can I do with them? Are they more than just environments to run silly 'dancing letters' applets? Yes, they are! In cases, they are very important to have. The most important example that comes into mind is the toonel.net client. Toonel.net is a free service to reduce Internet bandwidth usage. Please read my tutorial on setting it up on PPC devices. There're other examples too. For example, I've released a few tools for the Pocket PC's to, for example, to create your own custom word dictionary, to extract embedded sound (WAV) files from Pocket Notes (PWI) files or to demonstrate the NetFront DST problem. Also, as there is no decent compiler for the PPC platform. Forget the not-even-C-compliant PocketC, which requires the programmer to learn a completely new, WindowCE-specific - you can't use the experience you've gained anywhere else, unlike with Java or C#! - language & class library. It's just a toy if you compare it to the C# and the CF combo or Java, especially if you take into account the need for learning a new library and being developed by a small developer firm compared to Microsoft or Sun. There may be a lot of situations you need to do some specific task on your PDA (for example, writing/modifying a rudimentay HTTP proxy that deletes/modifies some HTTP headers or kills some ad HTTP requests to save bandwidth - this kind of coding can be finished by an experienced Java programmer in a few minutes and you really don't need a desktop computer for this) you can't do in popular scripting languages like MortRunner and you don't want to use any desktop computer emulator (for example, PocketDOS) on your PDA to write a non-native solution to do the stuff either. With Java, even program development and compiling are certainly possible. What JVM's are available now? Not many, but, fortunately, more than for the Palm OS, also with great hackability and real J2SE-compliance (unlike with plain CLDC/MIDP solutions). Insignia/Esmertec Jeode: this JVM is not sold any more except for the overly expensive Jbed version. Because this JVM was freely shipped with a lot of iPAQ devices and can be installed on any kind of PDA's, you may still want to use it. I certainly recommend it if you still have it lying around on some of your old iPAQ CD's. I really recommend this JVM if you still have it. It works great in almost all situations (with toonel, my tools or as a compiler) and has a very good 'hackability' factor. Installing it is pretty starightforward. If you install an old(er), but still perfectly usable version like 1.7.3, you may need to relocate it into a storage card because this version will only install to the main memory. You can relocate it to any card if you, after installing it, go to the \Windows directory and move Jeode.evm, evmawt.dll, evmcore.dll, evmpie.dll, iepluginvm.exe, hwawt.dll, javalib.dll, jdwp.dll, math.dll, net.dll and evm.exe from there to the new destination on yoru card. Make sure you also move the \Windows\lib subdirectory in there, so that the files that were in \Windows\lib are in a subdirectory called \lib in the new directory, just under the above-listed files. (I've also described this relocation here.) As with all the two other major JVM versions (J9 and CrEme), it has no registry entries so you can freely relocate it and/or just copy it from one device to another. This also means that you can have several versions of Jeode (or, for that matter, J9 and CrEme) on the same device - they won't interfere in each other. This is definitely a big plus, especially if you compare the capabilities of different versions of the same JVM and you don't want to do this on two different PDA's. IBM J9, Personal Profile 1.0: (please do not mistake it for the IBM J9, MIDP 2.0 version. The latter can't be used for running standalone applications. It only has Midlet support. To find out more about using it for running Midlets, please read this thread.) This is a very cheap (US$ 6) JVM, which also has a trial version. Excellent for running Java applications, even toonel. Its hackability factor is, however, much less than that of CrEme or Jeode. It can't function as a compiler either. For running already-made programs that only use Java 1.1, however, it's great. It's easily relocatable and also survives even a hard reset if installed on a memory card, just like with the other major JVM's. CrEme: a very fast (especially at compiling other programs, compared to Jeode) JVM. It renders AWT widgets/text different from Jeode/J9 though, which may be a showstopper in cases like running it on a VGA device. It currently has two versions: the PersonalJava (that is, JDK1.1.8) -compliant 3.x (3.26 is the latest) and the CDC1.1/MIDP1.0-compliant 4.x (currently in beta stage; 4.0b8 is he latest build). Which of the two? Most apps (including the compiler) will run using the stable 3.x versions. Furthermore, I've been unable to made toonel work with the current 4.0 beta version. Therefore, you needn't to run to pick the latest beta instead of a stable build. Can be used for compiling programs and has a good 'hackability' factor. A little bit of warning: if you execute the installer app on a desktop Windows that has a localized \Program Files directory (for example, the German Windows, which has \Programme instead), the installer will fail (this bug has been noticed also by me). This is a bug still present in the latest, 3.26/4.0b8 versions. You MUST run the installer app on a Windows version that uses the standad \Program Files directory name. NetFront JVM: this JVM comes with the Java-enabled NetFront Web browser. As of version 3.1 (I haven't tested the JVM shipped with version 3.2 yet, but, hopefully, will manage to do it in a few days), this JVM can be used to run some standalone programs (but definitely not all of them - it didn't run, for example, my ). Its 'hackability' factor is pretty low (again, see my posts on compilation at Pocket PC Thoughts); it can't really be hacked to run my NetFront DST problem demo. Installing The three stand-alone JVM's are very easy to install. J9 and CrEme can be installed straight to a memory card; older versions of Jeode must be relocated to there manually (it, again, isn't complicated at all). The JVM in NetFront gets installed with the NetFront browser - you don't need to install it by hand. (And, incidentally, you don't need to enable it inside NetFront either.) After installing the given application, it's ready to run anything. Running applications in Pocket PC JVM's Applications mostly come in JAR files. (For the Java-savy: you can also run individual class files in the four JVM's too. I've described this in my compilation-related article. This is best used if you also compile your Java programs on your PDA and . However, because most Java programs are distributed in a JAR file, to keep things simple, I only explain how JAR's should be run.) You'll need to put the absolute path (for example, \jars\someApp.jar) of these JAR files in the so-called 'classpath' variable, which you pass to the JVM executable file described in the next paragraph. Just like with any Pocket PC program, JVM's also have an EXE file to run. You must supply the JAR file path and the class that must be run to this program. The four JVM's need to be invoked the following way from the standard WindowsCE .lnk (link) files: Jeode: 255#"\<path to home directory>\evm.exe" -Djeode.evm.console.local.keep=true -cp <full JAR file path> <main class name> CrEme: 255#"\<path to home directory>\bin\CrEme.exe" -Ob -classpath <full JAR file path> <main class name> IBM J9: 255#"\<path to home directory>\bin\J9.exe" "-jclpro10" -cp <full JAR file path> <main class name> NetFront: "255#"\<path to home directory>\jvlite.exe" -classpath <full JAR file path> <main class name> You can create these link files by hand if not supplied. They only should contain one row - the one that has just been shown. You can put these .lnk files anywhere in your \Windows\Start Menu\Programs directory - they will behave like a "real" link file, just like the ones Windows CE is shipped with. The <path to home directory> is, for example, \Program Files\NetFront3\ with NetFront 3.1 installed into main memory, \Windows with Jeode installed into main memory, \<card name>\IBM PPRO10\ with IBM J9 installed into a storage card etc. You can easily find it with Pocket File Explorer or, even better, from the desktop using Total Commander with the WinCE file system plug-in. That is, if you decide to store your something.jar file in, say, \SD Card\something.jar, you'll need to pass "\SD Card\something.jar" (notice the " marks! They are needed if the path contains a space like in "SD Card"!) as the <full JAR file path> parameter. The second parameter passed to the JVM exe file is the name of the main class. With my programs, it's exactly the same as the JAR name. With, for example, toonel, it's gui.ClientForm. (For the Java-savy, you can't use the well-known <JVM exe name> -jar jarfilename execution form with any of the JVM's). If you are unsure/don't know this, rename the JAR file to a ZIP file and go into it with, say, Total Commander, Go to the META-INF subdirectory and read the MANIFEST.MF file in there. It'll contain something like this: Manifest-Version: 1.0 Main-Class: gui.ClientForm You'll need to pass the JVM EXE file the value that stands after the Main-Class attribute; that is, gui.ClientForm in this case. Please note that you will need to switch to the console mode with command-line batch variable support if you want to invoke your Java applications with varying parameters. You can pass parameters to your applications in your link files (the parameter(s) come(s) just after the main class name), but if you need to run your application on several different files to be processed (see for example my embedded-sound-PWI or user.dic-to-WinCE-wordlist converter), you may be better bite the bullet and install/get familiar with a console environment like PPC Command Shell, also described in my Java compiling-on-the-PDA article. The most important links on other tutorials/forums: Java on PocketPC, the Unofficial FAQ - perhaps the best and most up-to-date article/FAQ on PPC JVM's The focal point of Pocket PC & Java-related discussion Some other links (not as recommended as the two above!): Java Support on Pocket PC - a heavily outdated article; it contains a lot of links to non-exisiting JVM's. Java On Pocket PC Devices, Mikko Kontio - only discusses a small subset of running full-fledged Java apps on the PPC; still, may be worth reading for some JAVA for PocketPC PDA's - one of the most detailed articles (next to the Unofficial FAQ linked as first) on recent JVM's.