At a training session I recently attended, a presenter
mentioned that his cell phone crashes whenever he runs a simple
MIDlet that he wrote. While it may have been inevitable that
poor-quality environments would make it onto J2ME platforms, it's
still distressing to see some J2ME development proceeding down the
trail blazed by the megacorp in Redmond.
Now I am not one of those who despise Microsoft. Microsoft is
not inherently evil, and both good and bad have come out of it, as is
true of just about any corporate entity. But I do feel that
Microsoft's sins have been egregious in the area of software quality,
and I fear that it has inured us to accept software of far lesser
quality than we should accept.
When your desktop PC offers up the blue screen of death, you
may be annoyed and curse the denizens of Redmond, but most people
have come to accept occasional freezes and splats as one of the costs
of computing (or, at least, the cost of computing with Windows). But
there's no reason we should carry those diminished expectations to
Because the primary purpose of PCs is computing, it may be
easy to rationalize software failures as the price you pay, but the
primary purpose of cell phones is communication. For this reason - or
from a different perspective, because anything that impedes making
and receiving calls reduces revenue - most cell phone manufacturers
and network providers have historically been very restrictive about
what, if any, third-party software they allow on their handsets. If
customers can't make or receive calls, they'll be more inclined to
switch carriers, and they'll rarely make a distinction as to whether
it was the hardware, the software, or the network that was at fault.
This mentality contrasts sharply with that of the other major
platform for J2ME applications, PDAs, which have from the beginning
been first and foremost about applications. Since the early Palm
Pilots (and their precursors), the modus vivendi with PDAs has been
to download applications; so where cell phones restricted customer
deviation from a defined configuration, PDAs embraced it.
Consequently, PDA manufacturers and users may accept the occasional
crash, much like they do on PCs, as a risk worth taking. To what
degree are we willing to trade off the reliability of cell phones for
the convenience that downloadable applications add?
Shouldn't we first ask whether we need to make significant
trade offs? Is it not feasible to architect the KVM to be, if not
bulletproof, at least robust enough to prevent all but the most
onerous and insidious programming errors from significantly
compromising the reliability of the platform? Or is it that we could,
but it's not considered cost-effective to invest the extra effort to
do so? Or is it time-to-market that trumps the delivery of quality
Consider some of the vulnerabilities that poor quality
software could expose us to as cell phones become more powerful.
You'll have financial and other personal information on your smart
phone, but will it have enough computing capability to support virus
checker, or firewall software powerful enough to thwart sophisticated
attacks? Your cell phone's mobility combined with Bluetooth and WiFi
capabilities will allow it to be more promiscuous than a desktop or a
less-mobile laptop, joining and parting ways with numerous hotspots
as you travel around. Does ubiquitous computing mean ubiquitous
targets for compromised security?
Many efforts are afoot to address these concerns, and the
walled-garden security model of the KVM is a good foundation. But as
with building a house, a great blueprint counts for little if the
construction is shoddy. What can we do? As developers we can promote
high quality in the software we write, and provide informed voices in
discussions of the issues and in the development of specifications.
As consumers we can vote with our pocketbook, eschewing OEMs and
network providers who offer substandard services. But ultimately it's
the marketplace that will determine the quality provided.
About The Author
Glen Cordrey is a software architect working in the Washington, DC,
area. He's been using Java for five years, developing both J2EE and
J2ME applications for commercial customers.