Great, Free Java/Midlet Environment IBM J9 New, 6.1 Version is Out – a Full Compliance & Bug Report & Never Before Publi

IBM WebSphere(R) Everyplace Micro Environment (IBM J9 for short) is one of the best Java and Midlet environments for the Pocket PC (please see this tutorial on what Midlets are and how they can be used). If you make a generic search in my Pocket PC Magazine Expert Blog for "IBM J9" or look around in my full-blown Java-related articles (for example, Using Java on the Pocket PC - the complete tutorial (alternatives: FirstLoox, PPCMag); also, the "Java" sections in my Pocket PC Magazine Expert Blog are worth checking out), you’ll get numerous hits. The former Midlet article and the latter generic Java article are both worth checking out to see what midlets are capable of/usable for. Opera Mini, Google Maps, Toonel - just to name the three most important "killer apps".

The last version of J9 was released over a year ago – it took IBM a year to move to a new version. It was indeed worth the waiting - the midlet support is indeed definitely better than the previous version.

What’s new – in a nutshell

  1. Improved Midlet compliance – now, it’s fully compliant with all versions of Opera Mini Advanced (including the latest, 2.0 version). I didn't have problems with Google Maps either.
  2. VGA (high) resolution support, at least as far as text rendering is concerned, without having to use the native VGA mode on VGA devices. (Unfortunately, this only applies to text rendering. Rendering of graphics in standard SE VGA is still pixel-doubled, which will be a real pain with graphics-based midlets like the ingenious Google Maps. Then, you'll need to reboot the device into native VGA mode.) There're two separate versions for QVGA and VGA devices; I'll elaborate on the differences of the two in a separate section, with a lot of practical tips and tricks never published before.


The evaluation version of the Java/midlet suite can be downloaded here for free (note that the suite only costs money for customers that want to distribute it with their Java apps/midlets; end-users, as far as I understand, can freely download/access J9 without any trial/time restrictions. This scheme is pretty similar to "free for individual users, costs money for mass-deployers or hardcore business users" apps like the Oracle databases). Unfortunately, it requires (free) registration, the download section isn’t really intuitive (there’re several versions there; much as it’s not very hard for anyone that knows the Java and the WindowsCE terminology like the palm of his or her hand to get around; for others this may be pretty hopeless) and the download sizes are HUGE (compared to their real content, which is about an order of magnitude smaller than the EXE installers themselves). Unfortunately, as opposed to the previous version, Handango still doesn’t have these environments – that is, you’ll need to download the files off IBM’s site.

What are the differences between the two (MIDP and Personal Profile) versions?

In general, if you "only" want to run midlets (Opera Mini, Google Maps, some IRC clients etc), you will only need to install the MIDP version. If, on the other hand, you plan to run Java applications like Toonel, one of the greatest applications for the connected Pocket PC, you'll need the Personal Profile version.

Also note that, as with the previous Personal Profile versions, this version doesn't have a Pocket Internet Explorer / Internet Explorer Mobile Java applet plug-in either. You will still need to use either an old Jeode version or the best generic Java Virtual Machine, CrEme for this purpose.


Interestingly, as opposed to the previous, over a year old 5.7.2 version, this version doesn’t have any kind of CAB-based installer. This is a big problem because the "copy the files to the PDA" manual install method will scare away a lot of potential users.

All you need to do is decompressing the contents of the given ZIP file to any subdirectory on your PDA or storage card. You won't need to copy the doc and the examples directory to the destination. Also, you can safely delete every ZIP files that have (for example, end at) src/source (for example, lib\ and lib\jclMidp20\source\ to save space - they aren't needed either.

Note that both the MIDP and the PP versions can be installed anywhere; for example, on a storage card.

My registry script

As the installation is not CAB-based but involves manual file copying, there won’t be any kind of automatic registry imports either. The latter is very important – it’s a pity not even the official IBM documentation (see install.pdf in the doc subdirectory of each ZIP distribution file; these PDF files are also available with each version on the IBM homepage) explain the JAR/JAD file association with the MIDP environment so that deploying midlets becomes far easier. The way it is done without the registry import file I’ve created is much-much inferior to the traditional way of ‘just click the JAD file and it is automatically deployed in J9’. Exactly this is the way of deploying midlets that my registry import scripts makes it possible.

To do this, just download this registry import file, change all occurrences of "\\SD Card\\J9-MIDP\\" string in there (for example, with Ctrl-H and Change All in Windows Notepad) so that it points to the home directory of the MIDP J9 on your PDA and import it into the Registry of your Pocket PC (The file is in Regedit5 format and, therefore, you’ll need to use for example Resco Registry Editor to import it. Please see the Ultimate Roundup of Registry Editors for the Pocket PC for more info). After that, if you click a JAD file, it’ll be automagically deployed in J9 – you won’t need to follow the very-very-very awkward way the official IBM tutorial suggests. Strange the folks at IBM didn’t notice this really big problem – IBM has always been a bunch of really clever people (after all, I too have a high-end, 1600*1200 UXGA IBM Thinkpad notebook and just love it). The lack of CAB installer clearly show this product isn't really finalized.

VGA device users, attention!

As has already been pointed out, the MIDP version (the one that is able to run midlets) of J9 comes in two flavours: one meant for VGA Pocket PC's and one for QVGA ones.

Unfortunately, the VGA version, while it doesn't do pixel doubling on text (unlike the previous J9 version), still pixel doubles images as can be seen for example in this Google Maps screenshot (and all the other, VGA screenshots in this article; for example, this one). Therefore, you will need to switch to native VGA mode (please see my tutorials on doing this if you're unsure - VGA demystified - the definitive guide to OzVGA, SE_VGA and everything VGA-related (alternatives:iPAQ HQ, AximSite (the x50/x51 forum; the Tips and Tricks forum), PPC Magazine, FirstLoox)).

Strangely, the VGA-specific MIDP J9 version will not run in native VGA mode (as opposed to the standard SE VGA mode). This means you will need to stick to the QVGA version in native VGA mode. It will, as with the previous J9 version in native VGA, render images correctly in native VGA mode as can be seen for example in this Google Maps screenshot. As can be seen, there's no pixel doubling in this image.

Note that you can safely keep the two (VGA and QVGA) versions on the same Pocket PC. As they use the same deployed midlet repository in the file system (\My Documents\temp - strange they have chosen such a prone-to-be-cleaned-up directory name instead of putting everything in \My Documents\midlets or \My Documents\recordStores - the latter, now, only functions as a cache and settings directory for midlets), you can safely switch the J9 version you use - they both will find the midlets deployed in the other version, with all the settings and cache data and even current state to be resumed from, if available (as is the case with Google Maps, for example).

If you want to absolutely reduce (storage) memory consumption, you can safely switch the files bin\ivemidp20_23.dll and bin\j9midp20.exe - these are the only two files the QVGA and the VGA versions differ in. That is, if you, for example, only install the VGA version on your PDA but also have the bin\ivemidp20_23.dll and bin\j9midp20.exe files from the QVGA version at hand so that you can also use J9 in native VGA mode, in there, you'll only need to overwrite the two VGA-related files with these. (And vice versa.)

The Good

Better MIDP (Midlet) compliance

As far as the MIDP compliance is concerned, I’ve thoroughly tested the new version. It’s indeed a considerable step ahead. While the old 5.7.2 version couldn’t run the Advanced version of Opera Mini, the new version can. Everything works – for example, downloading files off the Web (a Pocket Loox 720 screenshot here; it works the same way as in the Intent Midlet Manager) – that is, just making the built-in Pocket Internet Explorer/Internet Explorer Mobile download the files. Note that you may have problems with this if you have let alternate browsers taking care of http:// URL’s. (In previous Opera Mini versions, it was, naturally, not available as can be seen in this Opera Mini 1.2 screenshot).

I’ve also tested the new version with the latest, version 4 beta of WLIrc 2.0, the best Midlet-based IRC application (see the roundup IRC Applications for the Pocket PC for more info if interested). Unfortunately, it’s still not possible to click the individual names in a names list; however, (some) commands entered to the text input field work (for example, whois) and so do private messages – that is, the situation hasn’t changed much from the previous version. An example screenshot is here (Pocket Loox 720) and here (x51v). On the x51v, the IRC midlet worked pretty OK, unlike Opera Advanced.

It IS compatible with WM2003(SE)!

Much as IBM only lists WM5 as the operating system version 6.1 of J9 is compatible with, it’s certainly not the case. I’ve been running it on my WM2003(SE) devices without any problem. An example screenshot of the WM2003 iPAQ 2210 running IBM J9 is here.

That is, you can safely install the new J9 version on pre-WM5 (WM2003/WM2003SE; earlier operating systems aren't supported) devices, it’ll work just great.

The Bad

The Personal Profile Version Still Isn’t Fully WM5-Compliant

On the other hand, the Personal Profile version, while, as opposed to the Personal Profile 1.0-only previous version already supports Personal Profile version 1.1, failed in my Toonel test. (Please see this article for the bug report of the previous version.) As you can see in this and this screenshots, the new J9 PP version still fails at running Toonel.

(A quick remark: if you plan to use an invocation (.lnk) command to start J9 PP and pass a Java class/JAR file to it, you’ll need to use the -jcl:ppro11 parameter instead of the old -jcl:ppro10 used with the older version if you download the PP 1.1 version. This is because the PP 1.1-compliant version doesn’t support PP 1.0; this is why you need to change this argument too).

Major incompatibility issues with the Dell Axim x50v/x51v in Opera Mini

Unfortunately, the midlet version of IBM J9 has problems with the VGA Dell Axim Pocket PC’s. It’s just unbearably slow with all versions of Opera Mini Advanced – while the same IBM J9 running on other Pocket PC’s renders pages instantly, you’ll end up having to watch the progress bar for dozens of seconds, even without not-that-big pages.

This is definitely not a storage card speed problem (I used exactly the same card and exactly the same configuration in my Pocket Loox 720), nor is it a problem with the high-resolution VGA version (the same VGA version runs in my VGA Pocket Loox 720 without any problems). It seems it’s another x51v compatibility problem. Unfortunately, there are compatibility issues with the x51v, even with the latest, A06 ROM: some other WM5 devices are far more compatible with current applications. Also see the case of Handmark Battleship 1.06 (see the story here).

It's not a WM5-specific bug either - my WM5 HTC Wizard runs J9-based midlets (including Opera Mini) just great.


A big thanks to AximSite user discord for pointing out the new version.

Modification history

First modification: May 9, 2006, 17:00 CET: added a lot of new information; for example, the differences of the QVGA/VGA versions.

Major addition: May 10, 2006, 9:00 CET: As (particularly now that AximSite has frontpaged my review) many users have reported (see this AximSite thread) the currently "killer app" midlet, Google Maps is running very slow, I’ve scrutinized the subject a bit more.

It's by far the slowest on my Dell Axim x51v – indeed a single tile loads for about two seconds (there’re several tiles on a map). It's considerably faster on my (not overclocked) WM5 HTC Wizard but not as fast as on my pre-WM5 devices (for example, Pocket Loox 720), where it is flying and loads anything almost instantaneously.

I’ve tried to completely relocate and, when I saw that it’s not possible, disable the midlet cache to see whether it’s the slow file creation/(re)write speed of the in-storage midlet cache that is causing this problem (see the last, "Results of trying to relocate J9-related stuff out of \My Documents in the main storage" section). Unfortunately, it seems this is not possible.

Not that I think relocating/disabling the cache would help – Google Maps is very slow on a WM2003SE (non-WM5) x50v too, where the record cache is stored in the RAM (which is much faster than Flash ROM). That is, it’s definitely a Dell compatibility issue (again, Google Maps is running astonishingly quickly on my non-Dell, pre-WM5 devices under J9 6.1).

All in all, Google Maps won't work on Dell Axim x50v/x51v with adequate speed and can't really be hacked to work either.

Hope IBM will look into the problem really soon. I don’t think the current version of IBM J9 6.1 is in any way final – the CAB-less install is a sign of this, or the “Milestone II-e Release Candidate†type remark in buildinfo.xml.

I’ll contact IBM on this matter.

Results of trying to relocate J9-related stuff out of \My Documents in the main storage

Both the midlet store (the directory (\My Documents\temp) that has a copy of all - renamed - deployed midlet JAR files, along with their description) and the cache directory (\My Documents\recordStores) take up precious main memory/storage. Therefore (in addition to trying to relocate the latter to a faster-than-the-ROM card from the slow(er) built-in ROM storage), I've spent some time on trying to relocate them to an alternative medium. Unfortunately, without any success.

There’re one occasion of the string ‘\My Documents’ in the J9 files (\bin\jclmidp20_23.dll at position 29d14 as can be seen in this screenshot). Unfortunately, hexediting it to point to a faster-than-built-in-ROM, heavily optimized won’t work as it seems J9 doesn’t use this.

There’s one occurrence of recordStores (not inside a method/class name) that provides the directory name where the midlet runtime cache is stored (\lib\jclMidp20\jclMidp20.jxe at position 26f7c as can be seen in this screenshot). It can’t be relocated either as it’s using relative-only paths (that is, starting the new path with a \ won’t work). I’ve even tried completely disabling the runtime cache by completely deleting this (just entering a 0 byte as the first byte, hoping that the built-in exception/error handling mechanism in J9 will still let for running midlets even when there’s no cache. Unfortunately, then, nothing worked – it was impossible to access stored midlets or deploy new ones.

Unfortunately, I can not host these files any more.

I'll re-check the IBM page and write a tutorial on how you can download J9 from there. (Unfortunately, Handango still doesn't have version 6.1.)

"Also, i wish to know if there is any other way to open, read n write to a normal text file in a PDA, basically normal file handling operations using Java VM like J9 or CrEme 4.2?"

Yes, FileInput/OutputStreams and Writers/Readers work without problems.

Nope, PE doesn't support midlets and vica versa.

BTW, XDA-Dev forum member "FOSA" has dposted a nice tutorial on getting the right installer from IBM here.

Yes, you can - they're completely independent of each other,

1, did you check out FOSA's instructions (see the 11/02/06 @ 11:54 comment)

2, the registry file is for the MIDP version, not for the PE one

Anz, since you have WinCE 5.0 (did you mean Windows Mobile 5.0?), you may want to prefer Jbed instead.

Why do you want to stick to the, in most respects, vastly inferior J9?

It's HERE.

Also see the MIDlet Bible HERE

Anz, use, then, the "UPDATE (11/24/2007)" section in the above-linked MIDlet Bible (it's at the end). It has a non-CAB-based distro.

You haven't imported the registry import file - therefore, there're no file associations set.

Should you want to avoid importing into the Registry, you can also locally search for the JAR files - put them in, say, the root of your handset and search for local files from inside Jbed.exe.

UnZIP the contents of THIS file to \Windows on your PDA.

Anz, Jbed shouldn't create any additional dirs - if you meant it and not J9.

Syndicate content