Screwtopia - Note To Self: Writing J2ME apps on Linux [entries|archive|friends|userinfo]
Screwtape

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Note To Self: Writing J2ME apps on Linux [Oct. 24th, 2008|09:30 pm]
Previous Entry Add to Memories Share Next Entry
A long time ago, I played with writing J2ME applets ("midlets" or "java games for phones") - back in the days when I was using OS X all the time. Recently a friend on IRC was asking me about J2ME development and I wound up trying to re-build my midlet. So that I don't have to re-learn all this stuff for next time, I figured I'd write it down for future reference.

The wrong way


The official way to develop J2ME apps is Sun's Wireless Toolkit. Although it contains lots of examples and documentation, it's pretty horrible in that it also includes a lot of confusing GUI tools and proprietary binaries, and it's only available for Windows and Linux/x86. If you're using a different architecture or OS, you're out of luck. Even on Linux/x86, it comes packaged as a 30+MB shell-script.

You might want to download the WTK just for the juicy documentation (you can unpack it with unzip instead of running the shellscript), but I'd just ignore everything else it comes with.

The right way


Things you need:

  • The ordinary Java Development Kit. In Debian, "sudo aptitude install openjdk-6-jdk"
  • The CLDC preverification tool. Although the WTK comes with a precompiled version, you can get the source under GPLv2 from here; or with Subversion from https://phoneme.dev.java.net/svn/phoneme/components/preverifier/trunk/
  • You now have the toolchain but you need the libraries to link against. My recommendation is to download the mpowerplayer sdk, which comes with a phone emulator for testing, and stub libraries for linking with.


How to build:

  • You'll need to set $CLASSPATH to the colon-delimited list of stub .jar libraries you downloaded earlier.
  • Each .java file needs to be compiled with the following options (for a MIDP1.0/CLDC1.0 application, anyway):
    -bootclasspath $CLASSPATH -target 1.1 -source 1.3
  • After being compiled, you need to use the preverifier tool you compiled earlier on the class:
    preverify -classpath $CLASSPATH -cldc1.0 $classname
    where $classname is the name of the class you want to verify, without any .java or .class extension.
LinkReply