Compiling java on the pda

[atrain]

I know its an odd question, but is there a way to compile and run java directly on the pocket pc?

I want to start learning java but im going to be away from computers for a while, so im wondering if theres a way to do this on my axim X5.

I know nothing about java on pdas, so please tell me everything i will have to know.

[Janak Parekh]

You may find this link (http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html) to be of help.

That said, the Pocket PC isn't an ideal way to learn Java. The Javadocs alone for 1.5 are 250MB/10,000 files... 8O

--janak

[atrain]

id use a tutorial...

thanx!

[atrain]

Hmm...
Those all look like JVMs...
im looking for JDK's that can compile directly on the pda...

Im begining to think there isnt such a thing...

[Janak Parekh]

Hmm...
Those all look like JVMs...
im looking for JDK's that can compile directly on the pda...
Right -- most Java bundles are JVMs, as the compiler is going to run fairly slow on a PDA and will eat up RAM. There was "jCompiler" on that list, though. No idea how well it works or if it's adequate. I personally learned Java on the desktop, and considering its verbosity ("public static void main", etc.), couldn't imagine doing it on the PDA. But more power to you if you can pull it off.

--janak

[Menneisyys]

Well, for quick prototyping/hacking/writing some tools on-the-go, even a PPC-based, "only" Personal Java or CLDC 1.1/MIDP 2.0-compliant JVM's are OK.

I'm testing the various tools for compiling Java on the Pocket PC. Serious hacking is involved because they're heavily outdated and have severe problems with currently available JVM's. Stay tuned :)

[Menneisyys]

Hmm...
Those all look like JVMs...
im looking for JDK's that can compile directly on the pda...

Im begining to think there isnt such a thing...

There are. It's just that you'll need to wait a bit until I sourt out all their bugs and hack them to be usable.

[Janak Parekh]

I'm testing the various tools for compiling Java on the Pocket PC. Serious hacking is involved because they're heavily outdated and have severe problems with currently available JVM's. Stay tuned :)
You have way too much time on your hands. ;)

Seriously, if you make measurable progress, fire off a news item to us and, if appropriate, we'll do up a DEVELOPER post.

--janak

[Menneisyys]

So... after several hours of serious hacking, I'm proud to present the working results :)

What you'll need?

1. Insignia/Esmertec Jeode. It has been shipped with higher-end iPAQ's from 2001, so, you may have it. I've tested version 1.7.3. Unfortunately, much as it was one of my main goals, I haven't managed to hack the freely downloadable IBM J9 JVM to work - it's unhackable, unlike Jeode JVM's. If anyone knows how you can generate J9-compliant class files so that I can enable compilation support with recompiling some classes in the java.lang package (unfortunately, this is a must to enable compilation with J9), please, let me know!

EDIT on 16/06 11:50CET: just move on to the next post if you want to know how to make it work with CrEme!

2. Jon Fernquest's IDE for Personal Java on the iPAQ. It's available here (http://www.angelfire.com/linux/jfernquest/mobileprog/pjavaide.html). Get the single ipaqide.jar (http://www.angelfire.com/linux/jfernquest/mobileprog/ipaqide.jar).

3. JDK 1.3.1_15 from here (http://java.sun.com/products/archive/j2se/1.3.1_15/index.html). Make sure you choose JDK and not JRE!

Why not 1.4 or 1.5, you may ask. It's simple: they are just not compatible with Jeode. I've tried hard to hack them to work - without success. (Again: please note that I've done all this with a relatively old Jeode version. Newer ones may be compatible with newer JDK's. Version 1.3, compared to the bare-bone C(L)DC/J2ME standards/implementations, is, however, pretty good.)

Install Jeode. If it's an old version (say, the above-mentioned 1.7.3), it's highly possible it can't be installed to any storage card. Much as they offer the installation-time option of an alternative storage media, it'll be still installed in main memory. It's, fortunately, pretty easy to relocate it to a storage card. I've described this here (http://www.pocketpcmag.com/forum/topic.asp?TOPIC_ID=16051).

Next, you'll need to fix a bug in the IDE: move the contents of the root of ipaqide.jar to a subdirectory called ipaqide inside it. The easiest way to do this is creating a ipaqide directory somewhere on your hard disk, stepping into it, renaming ipaqide.jar to ipaqide.zip, stepping into it, pressing + on the numeric keypad, pressing F6 and Yes (that is, moving). Then, move back the entire subdirectory to the ZIP file, and, finally, rename it back to ipaqide.jar.

EDIT on 16/06 11:50CET: I've uploaded the fixed version here (http://www.winmobiletech.com/062005JDKOnPPC/ipaqide.jar) so that you don't need to fix it yourself.


Next, copy c:\jdk1.3.1_15\jre\lib\rt.jar and c:\jdk1.3.1_15\lib\tools.jar to your PDA; preferably, a storage card. Let's assume you copy them to \SD-MMCard\jars\. Please note that the actual version number/JDK home path may be different from c:\jdk1.3.1_15; the relative path of rt.jar and tools.jar, however, is the same with all 1.2+ JDK's.

Now, create the following link file to invoke the IDE, along with adding rt.jar, tools.jar and ipaqide.jar to the CLASSPATH:

255#\SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \SD-MMCard\jars\tools.jar;\SD-MMCard\jars\ipaqide.jar;\SD-MMCard\jars\rt.jar ipaqide.Javacw2

In this example, I've assumed that JEODE is installed to \SD-MMCard\jeode\. If its path is something else, modify the invocation command accordingly, as with the case of different JAR paths.

Copy the link file to your PDA and run it. After some seconds, the GUI should be visible:

http://www.winmobiletech.com/062005JDKOnPPC/JavaPPCComplation-1.gif

Click the Open button. The contents of \My Documents will be displayed.

WARNING: if there is any file with real Unicode (>255 character code) characters in it, Jeode will crash with a UTF-8 problem in java.io.File().list()! This is because of the not-really-i18n-avare Jeode and can't otherwise be helped. Make sure you remove all files that have non-Western characters in their name from here before clicking Open.

EDIT on 16/06 11:50CET: in the next post, I've also described where, in what class file can you modify the default directory name so that you don't need to clean up \My Documents to make iPAQIDE work

Now, just navigate to the directory that contain your Java sources (if you don't want to start writing them from strach - if the latter is the case, just click New on the above screen). Double-click the file name you want to compile/edit so that its name becomes visible in the lower textfield:

http://www.winmobiletech.com/062005JDKOnPPC/JavaPPCComplation-2.gif

Click Open:

http://www.winmobiletech.com/062005JDKOnPPC/JavaPPCComplation-3.gif

On this screen, just choose the Java file you want to edit (so far, you've only added one, so, only one is visible in the lower pane). Click Compile to compile it (it'll be tolerably fast in cases; in other cases, it'll be very slow) or, if you want to edit it, just double-click it:

http://www.winmobiletech.com/062005JDKOnPPC/JavaPPCComplation-4.gif

From this editing screen, you can return to the first screen by pressing Return. Menu, on the other hand, takes you to the standard menu options, including Save As.

Note that, much as the GUI offers the Run button on the main screen, I haven't managed to run anything from here. You'll need to make a separate link file for invoking the newly-created class file. For example, if a HelloWorld.class class file is in the root directory of your PDA (the IDE stores the resulting class file in there), this link file should read as follows:

255#\SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \ HelloWorld

Just run it in a separate Jeode instance - you don't need to shut down the IDE process to do so. That is, just go to Start menu without closing iPAQIDE and click the link.

People that are interested in more PPC/Java-related stuff may also want to read the following threads:

Pretty instructive, but a bit outdated (there is no Personal Java for WinCE at Sun's site any more) and instructs to do far more than is really needed (http://www.aximsite.com/boards/archive/index.php/t-23426.html)
Open letter to SUN to produce a JRE for Pocket PC (http://forums.java.sun.com/thread.jspa?threadID=408223&start=0&tstart=0) - this is also very instructive. Shame on Sun for not releasing anything serious for the PPC!

Feel free to ask for help. Please also let me know if the images aren't visible from your PC. (I've just paid for the server hosting and would like to know how it works from around the world.)

[Menneisyys]

I have great news! I've continued playing with iPAQIDE and found out that CrEme (http://www.nsicom.com/Default.aspx?tabid=159) 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 (http://www.pocketpcmag.com/forum/topic.asp?TOPIC_ID=16017) 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

Some problems 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.

Compile-time 1.4/1.5-compliance:
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.

[bacchus_3]

WOW! that's great work menneisyys! I'll try this one over the weekend and see what I can do with it. Glad something works out even if it's not an official bundle...soon maybe it will :D

[paulzazzarino]

You guys are too much, actually a job well done! Nice to know that it is possible.

A couple of years ago I used the Netbeans IDE to build an app using RMI . Utilized the Remote Method Invocation model to call functions on a Server from Ipaqs using Jeode's JVM. Even implemented callbacks back down to the Ipaqs. RMI is pretty slick once you get it going.

Hopefully Remoting will be in the .NET Compact Framework soon!

[Menneisyys]

Thanks, I'll continue researching :) Will test all the other JVM's too and will even make a big roundup of all them, with hackability etc. info.

BTW, I've forgotten to state that you don't need iPAQIDE for compilation. It's just a tool to make it easier to edit / compile your files, but doesn't contain anything to actually compile source files - it just calls sun.tools.javac.Main.

Therefore, you don't even need to use it if you'd prefer using a third-party editor. Then, you will need to issue one of the following commands:

255#\SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \SD-MMCard\jars\tools.jar;\SD-MMCard\jars\rt.jar sun.tools.javac.Main \HelloWorld.java

(This is with Jeode; modify itt accordingly for CrEme. See my other example invocation files for the difference between the two JVM's.)

If you want as much flexibility as possible and, therefore, want to eliminate the need for link file editing for every java/class files you create, then, you may want to turn to a console application where you have the command memory of the well-known DOSKEY (in earlier MS-DOS versions, DOSEDIT) (up/down keys) and can call batch files with additional parameters. Then, the compilation/running of class files become really easy

(Please note that I've listed and scrutinized here (http://www.pocketpcthoughts.com/forums/viewtopic.php?p=343097) the Pocket PC-based console applications.)

I recommend the PPC Command Shell in Windows Mobile Developer Power Toys for this. Get it from http://www.microsoft.com/downloads/info.aspx?na=46&p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=74473fd6-1dcc-47aa-ab28-6a2b006edfe9&genscs=&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2f7%2f6%2f0%2f7606be4b-eea7-4515-83a0-81d7d9ac9ce1%2fWindowsMobilePowerToys.msi (the homepage is at http://www.microsoft.com/downloads/details.aspx?FamilyID=74473fd6-1dcc-47aa-ab28-6a2b006edfe9&displaylang=en ). Install it and after that, go to C:\Program Files\Windows Mobile Developer Power Toys\PPC_Command_Shell\arm. Copy console.dll to \Windows on your PDA and the two other files anywhere in the file system. Then, just start cmd.exe from, say, Pocket File Explorer.

From PPC Command Shell, you can execute batch DOS-like parametrizable files like the following two for compilation and invocation (running)

javac.bat: (for compiling files)
\SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \SD-MMCard\jars\tools.jar;\SD-MMCard\jars\rt.jar sun.tools.javac.Main %1

java.bat: (for running files)
\SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \ %1

Note that, unlike WinCE link files, they don't start with <number of remaining chars># and can be parametrized (hence the %1 for the first parameter; you can add more, especially for the second java.bat in order to pass command-line parameters to the class at runtime).

With them, you can compile/run your Java programs exactly like on your desktop machine:

javac HelloWorld.java
java HelloWorld

Please note that you don't even need to use batch files to compile/run Java programs - by just entering \SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \SD-MMCard\jars\tools.jar;\SD-MMCard\jars\rt.jar sun.tools.javac.Main HelloWorld.java and \SD-MMCard\jeode\evm.exe -Djeode.evm.console.local.keep=true -cp \ HelloWorldat the PPC Command Shell prompt, everything will work just fine. The batch-based solution is cleaner, though, and saves you a lot of typing / pasting at the first compilation/run.

http://www.winmobiletech.com/062005JDKOnPPC/PPCCommandShellBasedCompilationRun.gif

[yani]

Hi everyone,



A few years back I got an ipaq and I wanted to develop Java on it like I had been able to with my psion 5 (see http://www.hasiland.com/javaonepoc/javac.html)...the result, I created a wrapper similair to the Psion one. After a while I didn't have the time to maintain it, but since it was released GPL many others have forked the code base since then and continued it to my pleasure and amazement (I never realized the demand!). Most of the ones out there now are derivative works, a few I know personally are:



http://www.angelfire.com/linux/jfernquest/mobileprog/pjavaide.html
http://www.freaklamarsch.de/javacw/index.html



This article is the first I've heard of jCompiler, and I'm afraid that the app looks like another derivative of my original work, but not in complaiance with the GPL license I distributed it under (and without acknowledgment). Could someone who has bought this help me in determining if this is true? If the author distributes the source code with the app this is a non-issue, if not however then it is very concerning, especially since he is advertising that jCompiler is a 'Java compiler', and hence people who buy it are being misleaded the actual amount of work he did (see below).



I would like to demystify how these 'compilers' work. They aren't compilers (hence jCompiler is a very bad name) they are simple GUI interfaces to the Sun java compiler API. How does that work? Well the java compiler was written in Java by Sun (Yes I know, chicken and the egg but its true!) and included with most JDKs as a com.sun.javac.* set of classes. Thus nearly every JRE/JDK has the java compiler, or in the least the ability to run it. The GUI wrappers just provide an easy way to use the compiler on a pocketpc.



My original page for the project also included instructions on how to run Swing on a pocket pc, luckily some of that has been kept on http://www.freaklamarsch.de/javacw/index.html too.



Happy Compiling :-)

[Menneisyys]

Thanks for joining our discussion :)

Thus nearly every JRE/JDK has the java compiler, or in the least the ability to run it.

That's right. To put it more clearly for beginners, this means that, unlike JDK's, JRE's don't have the necessary classes for compilation. This is why I've also emphasized to get the JDK from sun.com, not just a JRE.

tools.jar, which contains the compiler package, is entirely missing from JRE distributions, and rt.jar is different from the full-fledged rt.jar of JDK's, which causes fatal issues at compilation time. Using a JRE rt.jar (instead of the JDK rt.jar) for compiling results in the same "package java.lang not found" error message as with the case of missing rt.jar (leaving it out entirely).

JRE's (and all PPC Java systems are JRE's), however, are able to invoke the standard compilation classes in the tools.jar (and the dependent rt.jar classes) shipped with JDK's. This is how the entire 'hack' (that is, adding a JDK rt.jar and tools.jar to the classpath and directly invoking sun.tools.javac.Main with the Java source file to be compiled can work on a PPC.

[yani]

Actually the only JRE I ever used (and the only free one at the time) , the Sun Personal Java Beta, included the classes. AFAIK most other Sun JREs also include the classes, although I haven't looked into it for a while so it is possible that has changed.



I have no idea why Sun decided to remove the JRE, it was excellent and quite stable. I can only guess that it would have hindered the market for the licensees such as jeode, et. all though and Sun also did not want to expend the costs for what they considered such a small market.



I guess JCompiler is also redistributing the com.sun.javac classes without permission or even acknowledgment in that case :roll:. What can I say, buyer beware.

[Menneisyys]

Actually the only JRE I ever used (and the only free one at the time) , the Sun Personal Java Beta, included the classes. AFAIK most other Sun JREs also include the classes, although I haven't looked into it for a while so it is possible that has changed.




OIC. I spoke of desktop JRE's, not Sun's old WinCE JRE. The former don't contain the classes necessary for compilation.

[Menneisyys]

I'm just trying to make use of the built-in PersonalJava-compliant NetFront 3.1 JVM. It seems this JVM can also be extended. I still have to combat some java.lang.SecurityException's (the comiler is run in application mode). Hopefgully will manage to 'hack' this JVM too.

[Menneisyys]

I've spent some hours today on trying to hack the Personal Java (JDK1.1)-compliant JVM that comes with NetFront 3.1 to be able to compile stuff with it.

First and foremost, it's not possible, for the following reason: sun.tools.javac.Main accesses a lot of java.* packages/classes. If you use a JDK 1.2+ tools.jar, it will (for example, right at the beginning of sun.tools.javac.Main.compile(), when it gives a call to sun.tools.util.CommandLine, which, in turn, tries to instantiate java.util.ArrayList etc.) try to access a lot of 1.2+ system classes. This will it make the compilation futile with additional 1.2+ libraries: any java.* package not in jvlite.exe won't be accessed.

I played around a lot with overriding the default security settings. I elaborate on them a bit because others may find this information useful.

In <NF home>/jre/, there're three subdrectories. They are separated based on the different scenarios the JVM can be used: as a stand-alone appletviewer, a NetFront applet JVM and a standalone application runner (general).

If you run the JVM in application mode; that is, by calling jvlite.exe, the security (and, incidentally, other config) files in latter, general subdirectory will be accessed.

jvlite.conf is for generic configuration. It allows for little customization. The security subdirectory contains the standardized Java java.security and java.policy files used.

Editing the package.access property in the former won't help because you can't disable the SecurityException when accessing third-party, not-with-NetFront-shipped java.* classes. The same stands for java.policy: much as you can supply a


grant {
permission java.security.AllPermission;
};


in here, it won't help the situation either. It seems the java.* protection can't be circumvented.

Unfortunately, unlike with other JVM's, the standard, shipped packages are all inside the jvlite.exe file and it seems to be impossible to hack them. So, there is no way of replacing them/copying there the new classes.

I've also tried to make compilation work with additional 1.1 libraries (classes.zip, without anything other in the classpath). This didn't work either: I was greeted with the well-known "No java.lang.Object superclass found" message.

Some tips for using jvlite as a JVM

It's impossible to keep the output of jvlite on screen - there is no related property in jvlite, unlike, say, in Jeode (the jeode.evm.console.local.keep property; see the command-line parameter -Djeode.evm.console.local.keep=true). The parameter javaconsole in jvlite.conf has notthing to do with this.

To be able to read error messages on screen if you want to run a class that exits as soon as it encounters an error (which results in jvlite's prompt exiting), you may want to write a proxy class that executes your class from it and, with a call to Thread.sleep(), force it to keep the console. A example: when I started to track down what caused the SecurityException during running sun.tools.javac.Main, I've written the following caller class, instead of invoking sun.tools.javac.Main by hand:


public class Compile {
public static void main(String args[]) throws Exception {
try {
sun.tools.javac.Main.main( new String[]{"\\HelloWorld.java"} );
}
catch (Throwable e) {
e.printStackTrace();
Thread.sleep(20000);
}
}
}


and called this instead of sun.tools.javac.Main from a lnk file. Then, I had the time to examine the exceptions.

Bottom line: it seems the hackability/upgradability factor of the Netfront JVM is pretty low and there is no way of making it work as a compiler.

[Menneisyys]

I've just posted a roundup of current JVM's, where to get them from, their set-up and command line invocation here (http://www.pocketpcthoughts.com/forums/viewtopic.php?p=351588).

[wilx]

Hi, thanks for all the great work. I am trying to get this going using CrEme, but I am not sure what you mean about the link file? is this a plain txt file ? what is the extension? what will I need to associate this with for it to run? Sorry if I am being thick

TIA

Wilx

[Menneisyys]

Hi, thanks for all the great work. I am trying to get this going using CrEme, but I am not sure what you mean about the link file? is this a plain txt file ? what is the extension? what will I need to associate this with for it to run? Sorry if I am being thick

TIA

Wilx

Welcome on the board :)

Link files are like standard icons in Windows. They are textual files with just one row. In my new thread at http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41081 , I've thoroughly discussed them too.

Please let me know if you don't understand something.

[wilx]

Hi
Thanks.... ok got everything going but had to go around the houses a bit as the Link files dont seem to like path names with spaces in like \My Documents\
will outline what I have done here incase it helps everyone else
using CrEme 3.26 default install to my CF_CARD

Jar Files Path \ CF CARD\jars
CrEme path \CF Card\creme\bin\

my command.lnk file (i have marked the start and end for clarity)
-------- START ---------
255#"\CF Card\creme\bin\CrEme.exe" -Ob -classpath \jars\tools.jar;\jars\ipaqide.jar;\jars\rt.jar ipaqide.Javacw2
-------- END ---------

When I make and edit a .java file it ends up in the " My Documents" folder. When I compile , .class file ends up here too.

I have installed the MS-Dos shell thing as outlined in an earlier post.
then in the root of my Pocket PC i have the following batchfile called Java.bat

-------- START ---------
cd My Documents
copy %1.class \
cd\
"\CF Card\creme\bin\CrEme.exe" -Ob %1
-------- END ---------

This gets round the fact that I can't seem to use spaces in path names
it will copy the .class file from the "My documents" directory to the root, then run that copy. So to execute you type "Java hello" at the prompt to run the hello.class file.
So now using this method I run the "command.lnk" to get the IDE going, and for compiling , and the DOS prompt to run the file.

I tried to get a batch file going to compile the code too, but it wouldn't work, It would run Creme, which said it couldn't find the .java file...if anyone knows what I'm doing wrong, please let me know... it is below:-
compile.bat

-------- START (THIS DOESN'T WORK)---------

cd My Documents
"\CF Card\creme\bin\CrEme.exe" -Ob -classpath \jars\tools.jar;\jars\rt.jar sun.tools.javac.Main %1
cd\
-------- END ---------

Or if anyone knows how to get it to accept path names with spaces, i wouldn't need to do the change directory and copying stuff

Anyway it works for now, and means I can have a play on holiday. Someone is bringing me in Jeode tomorrow, so might have a play with that too.

Hope this helps someone

[Menneisyys]

Anyway it works for now, and means I can have a play on holiday.

Great!

Someone is bringing me in Jeode tomorrow, so might have a play with that too.

I'd like to know whether it can be succesfully used for compilation. Could you check its version? I can't get hold of any version except for 1.7.3, so, I can't really check their compatibility...

[wilx]

Well I was hoping to get Jeode, someone said it was on the cd for an Ipaq. A friend bought the CD in today, but I can't find it. Any ideas where to get a copy?

[Menneisyys]

Well I was hoping to get Jeode, someone said it was on the cd for an Ipaq. A friend bought the CD in today, but I can't find it. Any ideas where to get a copy?

It's only bundled with few iPAQ models: 38xx. 39xx. 54xx. 55xx. It's no loger bundled with any recent iPAQ's, unfortunately.

So, you'll need to use CrEme. But it doesn't matter: it's much faster than old Jeode's.

[burtcom]

As I pointed out in another thread, the big problem with CrEme is that you can only use it for a short time (for evaluation) unless you can spend big bucks for licensing -- and they don't deal with anything smaller than 1000 units.

Everyone who's interested, please contact the makers of CrEme and tell them you'd like to see a reasonably-priced single-user license -- something like IBM's 5.99 license for J9 would be great :)

[Menneisyys]

I've continued playing with the current, 1.0.4 version of Mysaifu JVM (http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html), a promising, new, free JVM; now, compilation-wise (http://www.pocketpcthoughts.com/index.php?action=expand,40880). (Please see my last few posts here (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41081) on my other remarks on Mysaifu JVM).

Unfortunately, it doesn't work. (I used the link file 255#"\Program Files\Mysaifu JVM\jre\bin\jvm.exe" -Djava.ext.dirs=\ -cp "\" sun.tools.javac.Main \HelloWorld.java top compile; tools.jar and the JDK 1.3 rt.jar was in the root directory, as with HelloWorld.java.

(Incidentally, please notice the java.ext.dirs property. It must explicitly be set if you plan to put add-on JAR files in the classpath – just including them in the classpath (-cp/-classpath parameter), unlike with all the other Pocket PC JVM's, doesn't work.)

Unfortunately, with the additional JDK 1.3 rt.jar, the compilation doesn't work. If you, on the other hand, remove the additional JDK 1.3 rt.jar, you'll be presented the usual error message:

error: Package java.lang not found. Please adjust the classpath so that package java.lang is accessible.
\HelloWorld.java:1: Superclass java.lang.Object of class HelloWorld not found.
class HelloWorld
^
2 errors
JVM exit.

Unfortunately, Mysaifu JVM still needs a bit of work. However, it's really promising.