A recent J2ME-related announcement I find particularly interesting for a number of reasons is esmertec's demonstration of a MIDP 2.0 implementation on BREW. First, esmertec recently acquired Insignia, whose Jeode Embedded Virtual Machine for Java has made PersonalJava available on PDAs for some time. Is this acquisition the beginning of consolidation in the J2ME world, or an isolated incident?

Second, this is the first deployment of a MIDP 2.0 implementation I've heard of. While MIDP 1.0 has been available on BREW via Insignia products for some time, the final MIDP 2.0 spec was released just this past December, and the short turnaround time for Insignia's implementing 2.0 is a statement of their confidence in J2ME.

And finally, the availability of the MIDP on BREW benefits both J2ME and BREW. While BREW and J2ME are sometimes characterized as competitors, there are many reasons to consider them as complementary technologies. J2ME on BREW makes a much larger developer community and, consequently, a much larger set of applications available to BREW-enabled handsets. Conversely, BREW provides J2ME developers with ready-made services for provisioning, billing, and revenue collection.

One concern with the MIDP on BREW is whether the layering of the MIDP on top of BREW will introduce a significant performance penalty. Of course, one approach for improving performance on any JVM is the use of software techniques such as just-in-time and ahead-of-time compilation, which are as applicable in the J2ME world as in the J2SE world. But handheld devices also lend themselves to performance improvement via hardware enhancements that may not be applicable to or as attractive for PCs and servers.

I recently spoke with Jerry Steach of NanoAmp about one such technology, their MOCA-J product. This is a combination of a dedicated Java bytecode accelerator (206 of the 227 Java bytecodes are executed directly in hardware rather than being interpreted) and a cache. In addition to significantly faster execution of Java applications (NanoAmp claims a 20x improvement over the Sun reference KVM), hardware execution of bytecodes plus on-chip power management uses significantly less battery power than software execution of the bytecodes, and battery drain is always a concern with mobile devices.

The MOCA-J accelerator and cache are two separate dies bonded together that are in turn bonded to a flash memory die provided by a chip manufacturer. Since handsets already require memory, melding the MOCA-J with already-needed flash allows the incorporation of MOCA-J into the handset without using any additional circuit board space, also a significant concern with mobile devices.

For me one of the attractions of J2ME is the variety of technologies that come into play when considering the J2ME landscape. Interesting combinations such as BREW and J2ME, innovative hardware solutions (such as MOCA-J) to the resource limitations of mobile devices, and the incorporation of other technologies such as Bluetooth, all create a multi-hued palette that colors the J2ME landscape.

Here at JDJ the majority of our articles come from you, our readers. A reader will propose an article idea (via www.sys-con.com/java/authors), which we'll review for topicality and other factors. If the proposal is accepted, we then work with the author to scope the article size, review drafts, and move the article toward publication.

I ask you to consider sharing with our readers your experiences and knowledge gained from developing J2ME applications. It's a great way to make new contacts in the industry - after my first article I received e-mail from developers in Hong Kong and France - and having a "publications" item on your résumé can make it distinctive, which can be of particular value in today's tight job market. And there is always the personal satisfaction to be gained by attempting something different and out of the ordinary.