## J2ME

A nice article of J2ME programming made me wonder about alternatives to Java for J2ME development.

I know there are other apporaches to mobile development, including native Python on Nokia phones, but that's not what I am asking about. I mean languages that target the JVM. There are many alternative languages for the JVM. Do none of them provide J2ME support?

From what I could see Jython isn't an option since the interpreter alone needs more memory than found on normal phones.

## Comment viewing options

### SIMs

Did you know that J2ME/JavaCard is routinely used for writing programs that run on those tiny little GSM SIM cards? The applets can be compiled with free standard tools and then installed and remote-controlled by SMS messages. The catch for hobbyists is that you need to know the encryption key for your SIM card to be able to send it SMSes.

Currently the interface between a phone and a SIM card is a really simple bytecode-like format. For the curious here is an example of a command (in commented hexadecimal bytecodes) to update the "Serivce Provider Name" file on the SIM card, so that you see a different network name on the screen:

; SELECT   length  directory
A0A4 0000  02      7F20
; SELECT   length  file (SPN)
A0A4 0000  02      6F46
; UPDATE-BINARY  offset  length  data
A0D6             0001    05      'Test'FF


You can write your own bytecode interpreter in J2ME and install it as an applet. You get primitives for things like sending SMS and adding menu items to the phone.

I'm told that the next generation Phone/SIM interface will be based on HTTP and SOAP. The mind boggles!

### 3GPP specs

Have a look at 3GPP TS 51.011 for the phone/SIM interface and 3GPP TS 23.048 for details of encoding commands into authenticated SMS messages.

These standards are for 3G but the same information applies to 2G too. The only difference I know of between the 2G and 3G specs is that you have to pay a lot of money to the GSM association to read the 2G ones. :-)

NB: I don't know if this is the whole story for Phone/SIM interaction. My experience is with sending commands to SIMs rather than actually writing applets. If you want to play around I think you can find development kits with phone/smartcard emulators on the 'net.

### As long as we're on the subject...

As long as we're on the subject, Embedded has a couple of articles on a proposed B# language aimed at embedded systems with less than 65k of memory.

I can't say it particularly interests me because (a). I no longer work with embedded systems - the ideas are mostly about making an OO language with a small foot-print; and (b) no implementation is currently available for download. Still, the articles might be of interest for those that want to see the rationale for embedded systems spelled out in the popular press, or for those who care to make suggestions to the authors.

(Makes me wish there was a Programming Language equivalent to Ciarcia's Circuit Cellar of old, for those who design PLs in their basement).

### Hecl

I wrote a simple dynamic language that's small enough to be interpreted by the J2ME jvm, called Hecl . It's nothing particularly exciting in terms of a language, but since it's new, we're free to experiment with it as we see fit.

Of course I'm biased, but I think it's got potential - for less expert programmers, it makes it easier to write simple J2ME applications (you don't even need a java compiler), and for experts, having a dynamic language available leads to some interesting possibilities: you could download a script via http, store it, execute it, update it over time, and so on.

### Sounds interesting. I'll

Sounds interesting. I'll take a look.

### Assembly?

If you want something different, you could write directly in JVM bytecode :)

From what I understand, any language that outputs bytecode can target J2ME as long as it follows a few rules -- no floats, can only use a subset of the JDK, and a couple other things. There's post-processing tools to pre-verify the code (also required) and further massage the classfiles into the proper format.

The primary challenge in J2ME is to test against the myriad platforms available and deal with the subtle variations in API, while keeping things fast and small. There is a need for higher-level APIs which abstract over some of the incompatibilities between platforms -- J2ME Polish is one I've seen.