J2 Y-u-m-m-y points to be noted…

Fallacies of J2ME

The list of fallacies, according to Eric, are:

1. Java programs “will just work” on J2ME
2. KVM == J2ME
3. KVM == CLDC and CVM == CDC
4. J2ME replaces WAP

Fallacy 1: Java programs “will just work” on J2ME

Realistically, don’t expect to be able to run your existing Java applications unchanged on any J2ME platform. Apart from some technical issues (such as the CLDC 1.0 not supporting floating point), there will usually be two barriers: missing classes and resource problems. Not only do J2ME platforms subset the J2SE core classes, but they add some of their own unique classes as well. But even if you write code that only uses classes common to all the platforms you’re interested in, chances are that you’ll still have some work to do to optimize your application so that is uses less memory and has acceptable performance. Good design and modular programming will help a lot in this area.

This isn’t to say that you can’t reuse any code, just don’t expect to reuse it all.

Fallacy 2: KVM == J2ME

Many people use KVM and J2ME synonomously. They’re different things. The KVM is a Java virtual machine. J2ME is a set of specifications. Not every J2ME platform uses the KVM. The CDC, for example, uses the “classic” VM, not the KVM.

Fallacy 3: KVM == CLDC and CVM == CDC

In a similar vein, others use KVM and CLDC synonomously, or the CVM and CDC synonomously. Again, they’re different. The KVM and CVM are Java virtual machines, the CLDC and CDC are J2ME configurations.

The CLDC has specific requirements for its underlying VM, and the KVM can be configured to be that VM. The KVM in fact forms part of the reference implementation of the CLDC. However, there’s nothing preventing a specific CLDC implementation from substituting its own VM not based on the KVM source code. IBM’s J9 VM, used in recent Palm devices, is one such example. So is Research In Motion’s VM for the BlackBerry handhelds.

Similarly, the CDC has specific requirements for its underlying VM, and the CVM can be configured to be that VM. And yes, it too forms part of the reference implementation of the CDC. But CDC implementations can use their own VM, just like IBM uses its J9 VM in its CDC-based J2ME implementations.

Don’t get all worked up about which VM is used. As long as it passes the compatibility tests and meets the appropriate specifications, it generally doesn’t matter to you, the developer. The only time it matters is when performance is an issue and you’d like to switch to a faster VM. That said, remember that most handheld devices are closed platforms and only the platform vendor can actually install a different VM.

Cookie Caching

BES have the ability to handle cookies on behalf of client applications. In other words, any Set-Cookie headers sent back in HTTP responses can be intercepted by the BES (which is acting as a web proxy server) and stripped out of the response sent back down to the client. The cookie is then automatically inserted into subsequent requests by the client app when its request passes through the BES (again, in its capacity as a proxy server).

This cookie handling feature is not a feature but a bug according to Eric’s opinion. The basic problem is this: if a session cookie is used, there’s no way for the application to signal the BES that the “session” is finished. The normal behavior is for the client to clear session cookies when the session terminates. In a browser, this usually means when the browser is exited. In a J2ME application, the application simply stops sending the cookie in subsequent requests.

But since the BES is handling the cookies for you, when exactly does the “session” end? It doesn’t! So what happens is that you get a stale cookie being appended to your app’s requests.

The best solution? Turn off the BES-level cookie handling and let the application do the cookie handling by itself. All you do is set this property in the configuration file:

application.handler.http.CookieSupport = false

You can also set it directly from the BES management console.

Fallacy 4: J2ME replaces WAP

WAP is a set of technologies for wireless communication. It includes a markup language called WML for writing browser-based applications. You can find out more about these technologies at WirelessDevNet.com.

WAP and J2ME are different things, and each has its place when it comes to application creation and deployment. WAP (or really, WML and WMLScript) lets you build browser-based, thin-client applications optimized for wireless delivery. J2ME lets you build “thicker” client applications with more sophisticated logic and the ability to run in an “offline” mode. It’s really like trying to say: “which is better, a page of HTML or a Java applet?” Both are different, and both have their uses. Hopefully, though, J2ME won’t suffer the same problems that caused applets to fall out of grace so quickly. This is why the standardization process, industry support, and compatible implementations are so important for the success of J2ME.