SD TImes: Software Development Click for BZ Media
Search
NewsCurrent IssueBack IssuesColumnsOpinionsResource LinksSubscription services
About UsMedia KitSite MapContact UsHome

Advertisement







JAVA WATCH: Is Micro Java Too Small?
By Steven J. Vaughan-Nichols

Steven J. Vaughan-NicholsJanuary 1, 2002 — It sounds like a good idea: Why not put Java into handheld devices with a version designed for a small memory footprint and low-powered—in every sense of the word—16- and 32-bit processors? The result, of course, was the Java 2 Platform, Micro Edition (J2ME).

J2ME is meant to run in devices with as little as 160K of memory while retaining enough standard Java APIs to be useful to Java programmers who cut their teeth on J2EE. And, as you can probably guess, J2ME is also meant to be upwardly scalable with J2SE and J2EE and for its code to be interoperable between devices using J2ME. Haven’t we heard that tale before in different environments?

In practice, for J2ME to be useful on mobile devices, it also needs the Connected Device Configuration (CDC). The CDC J2ME implement provides for a virtual machine, typically the C Virtual Machine (CVM) with core libraries. To put that to work, your platform requirements suddenly jump to a 32-bit processor and 2MB or more of memory, which the specs say can be either RAM, ROM or flash. Let’s be real. You’re going to need 2MB of RAM.

Of course, you can also try the Connected Limited Device Configuration (CLDC) route. In this approach, you may be able to squeeze in at 160K using Sun’s no-frills K virtual machine (KVM). Of course, if you want your J2ME device to communicate with the outside world wirelessly—and what’s the point of even building these things without that functionality?—you’ll also need to add in the Mobile Information Device Profile (MIDP). To make a long story short, you’re going to quickly break that 160K minimum memory requirement.

Some programmers have also told me that they’ve found it hard to dynamically add a library to the KVM to allow them to add functionality to their devices. As it is, if you want to add a new feature to the J2ME in, say, a cell phone, you can pretty much forget about simply updating the software.

Still, a quick survey of Bill Day’s listing of J2ME Emulators/Simulators, SDKs and IDEs reveals that almost all current development work is aimed at CLDC/MIDP instead of CDC/CVM. (Day is Sun’s technology evangelist for J2ME and maintainer of the J2ME Archive at http://billday.com/j2me).

One problem here is that programming in anything at the embedded level, or close to that level, isn’t easy. Since J2ME isn’t real-time, I don’t count it as an embedded system. But, J2ME comes as close to embedded programming as most Java developers will ever get. Some insist on looking at J2ME as just a better client-side implementation of Java. They’re underestimating the programming skill needed at a level where every byte counts.

There are some development tools available. Besides the usual support from Sun, third-party handheld OEMs, like Motorola, Nokia, Palm and Research in Motion, are delivering SDKs. And, Borland is now shipping its JBuilder Handheld Express. Other smaller software houses like 4thpass, Aligo and Covigo also have J2ME development tools.

Heck, there’s even real-world product shipping with J2ME running. The Nextel Motorola i85s brought stand-alone J2ME apps to a mobile phone last summer. Now, with the i90s, J2ME with CLDC support can be used to build network-aware programs. The first is SSL support for secure HTTP data transfers from this cellular phone.
From a consumer’s viewpoint, however, the most important plus of this J2ME-enabled phone is that Nextel Wireless Web subscribers will be able to use over-the-air application downloading to grab new Java applications, so long as they’ll fit into the device’s 384K of RAM. Never underestimate a device that enables users to grab new games even if they turn out just to be Java versions of Minesweeper.

When you’re developing for specialized, low system resource devices, I don’t care how good your tools are, you’d better know just how J2ME is working with the underlying embedded operating system and hardware at an intimate level or you’re in for a world of hurt. That’s hard work. That’s time-consuming work. Can you and your team afford it?

Don’t mistake me; I’m sure some Java developers will be buying Porsches as a result of their J2ME work. But I think it will be only those developers who have business managers with existing strong ties to the handheld device and mobile phone powers who will strike it rich.

And, would it surprise you to know that Microsoft will soon be revealing .NET Compact, their answer to J2ME? Sources at Microsoft tell me that they already have a trio of major mobile vendors who will be deploying .NET Compact using Windows CE for mobile phones (an operating-system code named Stinger).

While I can understand the J2ME temptation, I think the inherent problems with limited environment programming and upcoming Microsoft competition make it too expensive for most Java development shops. Do you want to make money in 2002 from Java? I’d stick with J2EE and servers.




Steven J. Vaughan-Nichols has been writing about technology for more than 15 years and also has worked as a programmer for NASA and the Dept. of Defense.


Columns
Alan Watch

And Another Thing

Book Watch

JAVA WATCH

Middleware Watch

Money Watch

Web Watch

Windows Watch

E-mail your comments to sjvn@vna1.com

Advertisement

Click here for a complete listing of Java Watch Columns.

Click here to see a complete Column Archive.


 

 

 

 

 

 

 

 

 

 

 

  


































Back to Top



news
| current issue | back issues | columns | opinions | resource links
about | site map | subscriptions | media kit | contact us

Copyright © 1999-2002 BZ Media, LLC, all rights reserved.
Phone: 516-922-2101 • E-mail:info@bzmedia.com