Into the Supposed "Hellfire" of J2ME: Part 1

I get the feeling from the comments to my last post that the journey through J2ME is going to be a painful one.

So after about 2-3 hours of lazy research here's what I've found out so far about the technical side of J2ME:

  • Every J2ME device has to provide a CLDC (Connected Limited Device Configuration)
  • A J2ME device implements a MIDP (Mobile Information Device Profile)
  • Setting up a J2ME development environment on GNU/Linux (I'm using Debian if that matters to anyone) is not going to be straight forward.

Let's clarify what these terms mean.

The CLDC exists so that every J2ME-enabled device provides a definite set of functionality. It turns out in reality that this is not entirely accurate. A lot of developers mention how J2ME is fractured by the differences in the behavior of devices' J2ME implementations. We'll see how that affects my development. Essentially CLDC is a minimal set of classes from the standard Java edition (Java SE) that allows the Java virtual machine to operate.

An MIDP is another set of functionality that is supposed to be the same across devices. There are several versions of MIDP, the most common being MIDP 2 (released in 2002). As far as I know, the latest and last version is MIDP 3, released on 2009/12/09. Since most devices use MIDP 2 lets see if there is anything interesting in the specification document.




...We have a list of what MIDP 2 devices should be able to do.  I'm happy the documentation also opens after 12 years because it isn't in some obscure help format.

Mobile Information Device Profile 2.0

User Interface Package
javax.microedition.lcduiThe UI API provides a set of features for implementation of user interfaces for MIDP applications.
Game Package
javax.microedition.lcdui.gameThe Game API package provides a series of classes that enable the development of rich gaming content for wireless devices.
Application Lifecycle Package
javax.microedition.midletThe MIDlet package defines Mobile Information Device Profile applications and the interactions between the application and the environment in which the application runs.
Networking Package
javax.microedition.ioMID Profile includes networking support based on the Generic Connection framework from the Connected, Limited Device Configuration.
Public Key Package
javax.microedition.pkiCertificates are used to authenticate information for secure Connections.
Sound
javax.microedition.mediaThe MIDP 2.0 Media API is a directly compatible building block of the Mobile Media API (JSR-135) specification.
javax.microedition.media.controlThis package defines the specific Control types that can be used with a Player.
Persistence Package
javax.microedition.rmsThe Mobile Information Device Profile provides a mechanism for MIDlets to persistently store data and later retrieve it.
Core Packages
java.langMID Profile Language Classes included from Java 2 Standard Edition.
java.utilMID Profile Utility Classes included from Java 2 Standard Edition.

Seems pretty standard. I like how the list of packages and their descriptions fit on my monitor too.

Ok now that we know a little bit more about the platform we're using, lets setup the environment. Put on your gloves, this is going to get messy. Ok now take them off; I lied. It is surprisingly easy to setup the environment.

Our journey begins by downloading and installing the Sun Java Wireless Toolkit 2.5.2 (commonly referred to as the SJWT), that was released in 2007. The installer is pretty old school. I had to agree to a licence agreement by typing in yes, then specified my JDK path. It asks for Java 2 SDK, but I specified OpenJDK 7 and the installer accepted it. My path was: /usr/lib/jvm/java-7-openjdk-amd64/bin. I installed the toolkit in $HOME to know where files were going.

After installation, the installer gives you one last helpful message:
In order to start using the Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC, please run
~/WTK2.5.2/bin/ktoolbar

So I ran that and a nice little window appeared.

A nice window. Isn't it nice?!

So I'm a little lost at this point, and decide to click on "Open Project ..." to see where this looks for code. To my surprise there were a bunch of demos!



I went ahead with UIDemo, because I wanted to learn a little more about the way UI was done on the J2ME platform.

And this is where my journey stopped. It turns out SJWT requires a 32-bit JRE. My AMD64 JRE was totally non-compatible with it, even though it's supposed to be able to run 32-bit Java applications. SJWT was looking for some specific 32-bit class...Here is a short excerpt of the error for those who know if it's possible to get this working under a 64-bit JRE:

java.lang.UnsatisfiedLinkError:
/home/fer/WTK2.5.2/bin/sublime.so:
/home/fer/WTK2.5.2/bin/sublime.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

(I'll leave out the stack trace...)

Soooo yeah. Until I get a 32-bit JDK installed, I'm stalled.

Besides that I think SJWT is pretty neat. Developers do all their development in editor of their choice. SJWT acts as a configuration manager. To be honest I haven't really seen anything like it before...Could just be my inexperience showing. Another neat feature of SJWT is that it provides several emulators.


Didn't get to try any though. The next part of this series will definitely include them.

To conclude, J2ME development so far seems very straight forward. There have been no difficulties obtaining the correct development tools; the documentation is clear and easy to navigate; SJWT provides what appears to be a simple, easy to navigate interface to configure applications. I hope this trend continues.

Initially I was going to code a Google Hangouts client, but the API is JavaScript-only, and I don't have time to code wrappers. Then I was debating between a Tox or IRC client. I won't be doing Tox though because it requires a re-implementation of the Tox server, the protocol is somewhat complex to totally code from scratch and then an implementation for the client. IRC in contrast has an extremely simple protocol and only requires the client to work. I figured it'll be best for this J2ME learning experience.

If there's anything specific you'd like to see in this post or in the next, let me know in the comments!




Comments

Popular Posts