I have great news!
I've continued playing with iPAQIDE and found out that CrEme
also works great with iPAQIDE !
Basically, both version 3.26 and 4.00beta will work. The only difference is the JDK version/Java conformance they have. The most notable difference, in addition to the different JDK conformance they have, is that 3.26 can't step out from the initial \My Documents
by clicking Up. Therefore, put all your sources there or in some of its subdirs; or, alternatively, modify, recompile and repackage the default constructor in ipaqide.Javacw2
(the sources are in the iPAQIDE JAR file); it's in the curDir = new File("\\My Documents");
assignment that the initial directory is set.
Before deciding for 4.00beta over 3.26, however, you should also be aware of that it does
have a lot of bugs. One of the bugs is, for example, that I wasn't able to make it work with the new (still unpublished; I've only got it for testing), entirely CDC-compliant version of the toonel client
because it has Socket-based input stream bugs. Therefore, as a runtime
environment, you may want to opt for the older but stable version, if 1.1.8-compliance with the system classes (java.*
packages) is sufficient.
The best thing is that, like Jeode, CrEme doesn't need to be hacked
- if you just add tools.jar (the jar file that contains the classes needed for compilation, starting with sun.tools.javac.Main.main
) and rt.jar to the compile-time classpath, everything will be fine.
The script to call CrEme installed into main memory:
255#"\Windows\creme\bin\CrEme.exe" -Ob -classpath \SD-MMCard\jars\tools.jar;\SD-MMCard\jars\ipaqide.jar;\SD-MMCard\jars\rt.jar ipaqide.Javacw2
And, a storage card-based installation:
255#"\SD-MMCard\creme\bin\CrEme.exe" -Ob -classpath \SD-MMCard\jars\tools.jar;\SD-MMCard\jars\ipaqide.jar;\SD-MMCard\jars\rt.jar ipaqide.Javacw2
concerning running non-CDC (4.00beta; with 3.26, non-Personal Java) compliant Java programs:
- additional classes contained by Java when compared to the CDC 1.0/JDK1.3.1 supported by CrEme 4.0 (Personal Java/JDK 1.1.8 supported by 3.26) the are found and used in rt.jar (for example, the java.lang.StringBuilder
in 1.5). Running these programs require no additional hacks.
- old, but updated
classes (for example, the new getRemoteSocketAddress()
method in java.net.Socket
) in rt.jar are, however, shadowed
by the system library. I have played around a lot with hacking \Windows\CrEme\lib\VMclasses.zip
by overwriting first the java.*
, then also the sun.*
packages; without success (other people having more free time, however, may have more success at this.). This means, at present, I don't know any way to run Java programs depending on system classes that have additional methods compared to the CDC 1.0 specification.
That is, you won't run be able programs that use, say, the above-mentioned java.net.Socket.getRemoteSocketAddress()
. You'll need to modify (reimplement the same functionality using older constructs / methods) and then, recompile these classes to be CDC- and, therefore, CrEme compliant. Then, incidentally, they will also become IBM J9-compliant, so, you may want to opt for using the free J9 instead of the commercial CrEme.
Unfortunately, much as Creme doesn't report the same error than Jeode with JDK1.4/1.5 (that is, it's at least able to run Java programs using even the latest Java versions), it's unable to compile because of sun.tools.javac.Main
's being deprecated. (The above-linked thread in the Sun discussion board discusses this problem too, along with a lot of other articles/threads; now, there is no standardized
way of compilation.)
Other differences between CrEme and Jeode
(why would you want to choose one over the other etc):
- the text editor/any text output in CrEme is much worse/slower and is low-res on VGA devices
- CrEme can be far faster at compiling than Jeode
- the speed difference can even be tenfold. For example, Jeode compiled a simple Hello World program in 28 seconds, while CrEme 4.00b in one.
- CrEme is available for download/purchase, unlike Jeode.
- it displays the main menu bar, unlike Jeode. It offers little, though; all that functionality is accessible through the buttons as well. BTW, the Compile/Options
doesn't work - it's just not "wired in" in the application, so, it's futile to try to make it work.
- its GUI is far worse-looking than that of Jeode (especially the source editor), though.