Since Java ME comes in several flavors that Hecl can be compiled for, it's necessary to understand what Hecl does, and how it does it.

JavaME has two layers that are of interest to us, "CLDC" and "MIDP". CLDC is available in 1.0 and 1.1 configurations, whereas MIDP comes in 1.0 and 2.0 configurations. The most common configurations are CLDC 1.0 and MIDP 1.0, CLDC 1.0 and MIDP 2.0, and CLDC 1.1 with MIDP 2.0. Here are the Wikipedia entries describing CLDC and MIDP.

Hecl tries to match code to system resources: in other words, the code in the midp10/ and midp10gui (MIDP 1.0) directories is smaller, simpler, and has fewer features than the code in midp20 and midp20gui (MIDP 2.0), reflecting the fact that many 1.0 devices only allow very small jar files ("midlets").

For MIDP 1.0, the midp10gui directory contains the GUICmds.java, which has most of the functionality that maps J2ME functionality to Hecl and back. The midp10/Hecl.java file contains the code that starts up Hecl on the cell phone. For MIDP 2.0, the midp20gui directory contains the GUI commands, and midp20/Hecl.java is where the application is launched from on the phone.

In order to be able to deal with all these different versions, Hecl is more or less forced to utilize a Java preprocessor, which explains all the ifdef's in the code. The various symbols are defined in the settings.xml file.

To compile different combinations of things, Hecl makes a couple of property files available that are used like so:

 ant -propertyfile ./cldc10midp10.properties midlet
      

Which compiles the CLDC 1.0 / MIDP 1.0 version of Hecl and places the jar in the jars/cldc1.0-midp1.0/ directory, or:

 ant -propertyfile ./cldc11midp20.properties midlet
      

Which compiles the CLDC 1.1 / MIDP 2.0 version, and places the jar in the jars/cldc1.1-midp2.0/ directory.