Programming Wireless Devices With Java 2

Jeff Carroll writes "Developers building Java applications for wireless handheld devices have been looking forward for some time now to the release of devices supporting version 2.0 of the Connected Limited Device Configuration (CLDC), and version 1.1 of the Mobile Information Device Profile (MIDP). These new releases contain support for features demanded by developers that didn't make the original releases. In support of CLDC 2.0 and MIDP 1.1, Roger Riggs and his team of authors from Sun, Nokia, and Motorola have released Programming Wireless Devices with the Java 2 Platform, Micro Edition, Second Edition (since I don't have a copy of the first edition, I can only evaluate the new edition on its own merits)." (Read on for his review.) Update: 07/23 16:31 GMT by T : Whoops -- that's CLDC 1.1 and MIDP 2.0, not the other way around. Programming Wireless Devices with the Java 2 Platform, Micro Edition, 2ed. author Roger Riggs, Antero Taivalsaari, Jim Van Peursem, Jyri Huopaniemi, Mark Patel, Aleksi Uotila pages 464 publisher Addison-Wesley Professional rating 7 reviewer Jeff Carroll ISBN 0321197984 summary In-depth introduction to and reference on CLDC 2.0 and MIDP 1.1.

As is characteristic of the titles I've seen from Sun's Java series, this book goes into great detail about architectural decisions, standards process, and philosophy underlying the new release. The first six chapters are given over to this discussion. This material is mostly great for experienced developers seeking a deeper understanding, occasionally so abstract as to be silly (as in the case of the Java washing machine and its downloadable stain-removing code), but likely to be of only secondary interest to new J2ME developers focused on coming up to speed.

What this book does best is comprehensive exposition of the J2ME APIs. There are chapters dedicated to the APIs for forms, graphics, games, sound, persistence, and networking, with code samples offered in most cases, and a Java Almanac-style reference to all J2ME-specific classes and interfaces is provided as an appendix. Features that are new to the J2ME second edition are clearly identified.

The remainder of the book constitutes a detailed discussion of the new technologies for event-driven launch, application security, and over-the-air deployment, perhaps the most potentially confusing of which is event-driven application launch. While the book explains the new technology well, it doesn't address how it will be introduced by network operators, or how it might interact with or replace similar existing proprietary technologies such as Sprint's MUGlets.

Another subject that is not dealt with here that will soon be relevant to developers for any particular J2ME-supporting network is that of optional packages (OPs) - features to be supported at the option of particular device vendors and/or network service providers. It is fairly clear that, going forward, the wireless network infrastructure and its supported features will be an integral part of the J2ME platform that will have to be taken into account by developers, and books which fail to discuss popular and commonly adopted OPs will be of limited usefulness (you'd think that Sun would know that after all that rhetoric about the network being the computer). In general, a book of this sort would benefit from the participation of network operators, as it does from that of device manufacturers Nokia and Motorola.

All the code samples and background on architecture notwithstanding, this book is clearly targeted at experienced Java programmers, not handheld device programmers working in other technologies. If you don't already know Java, this book will not teach you. There is also nothing said here about selection, configuration, or use of development tools; readers who are not already adept at the use of J2ME development tools, including the Wireless Tool Kit (WTK), should not expect to acquire that knowledge from this book. (People who need help in this area may want to consider Jonathan Knudsen's Wireless Java or Kim Topley's J2ME in a Nutshell.)

Keeping the aforementioned caveats in mind, this is an excellent introduction to and reference on the new release of J2ME.

You can purchase Programming Wireless Devices with the Java 2 Platform, Micro Edition, 2ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Games?

[Nick of NSTime]

Could this be applied to wireless games on cell phones?

Java woes

[Mondoz]

It's great that there's more support for the actual wireless aspect, but there's not enough Java support for the other devices that interact with the wireless.

For example, I'm working on a project that involves a barcode scanner attached to a PDA, communicating wirelessly to a database. Java might let me do all the wireless/database stuff, but so many addon devices don't support Java.
Anyone know of a PCMCIA or CF barcode reader that does suport Java?

(crickets chirp)

Re:I thought Java was doomed

[__past__]

What's the fastest runtime for Python? Can it translate to C code?

Nope, it goes directly to machine language. Plain old CPython with Psyco, that is.

My personal quest has been for a productive, portable language that's efficient enough for high-end gaming applications.

Try Lisp. No, seriously. Think GCs and (native-code) compilers with 40 years of optimization, together with a really high-level, productive language. See this example where it seems to have worked quite well.

Re:Java Isn't Trustworthy

[BFKrew]

Totally disagree with you I'm afraid.

To say that someone who is writing in Java is not writing a "serious program" is wrong. If I wrote a program for a mobile phone that interacted with an Exchange server, imported XML documents from your company intranet and performed some processing before presenting the result etc is not a trivial matter, but I do not need to necessarily to understand the low level details - which Java hides really well.

too right, mate.

[mekkab]

For right or wrong, a lot of hardware vendors seem to assume that people using high-level languages aren't writing serious programs. As a result, they don't bother to fully implement their interfaces.

Nor do they bother to comply with standards. Despite providing PCI token ring cards for their new e-servers, don't expect a device driver that is standards compliant from IBM. Never mind that we run a real time human grade system (thus, the olde skool token rings!)

I seem to remember another slashdot article (or was it a Journal Entry?) where a managing engineer asked a company to buy a license to see and modify a device driver, threatening to take their VERY BIG contract away. The companies response was a list of their 3 competitors. They would rather lose money than give up any "Secrets!" (secrets being defined as "turn on this poll bit of the PCI controller at this address", or something to that effect)

IBM used to print up GREAT guides for their hardware- how to check the Power Status registers or the front panel key position on their RS/6000 machines (what registers, what offset, etc.)- Now, they won't even give you an assembler reference manual for their POWER4 chips ("just look at the powerPC stuff, its close enough...")

Re:Too Complex

[FatherOfONe]

I agree with our main point. However don't blame Sun too much for the crap that was KVM. Remember they turned that over to "PALM" to head up. I never understood that at all. Why would Palm EVER want to support JAVA? They owned like 90+% of the PDA market. They want people to write to their platform, not a generic one, that would let people move off of Palm.

I currently have an Ipaq, and it runs java via some JVM supplied by compaq. It looked cool and I thouht it would be great because this thing runs at 400mhz! Well, it doesn't support SWING... man that kinda sucks for what I would want to do with it.

Re:Too Complex

[nate1138]

If you want an easy to code PDA platform, try Ewe. It's got a full featured class library, a fast-ass VM, and it runs on anything (PocketPC, Linux, win32, mac). We've been using it to deploy wireless pocketPC apps, and it rocks.

APIs Are Serious

[Vagary]

Um, did you or any of the asshat moderators bother to read my post or did you just interpolate from the highlighted word?

My point is that without the APIs encapsulating the hardware interfaces you can't write serious programs in Java, not that you shouldn't. How is your mobile phone going to interact with that Exchange server if you can't even use the phone's network interface? If the J2ME API is not fully implemented, then you're trapped in a little mobile jail.

I was arguing that industry has shown itself unable to properly implement APIs for high-level languages, so therefore volunteers need to implement them. As a result, someone needs to know the low-level language because Java can't be used to write its own APIs. Java can be used for serious programs, but only after someone else does some programming in a lower-level language.

Re:APIs Are Serious

[juanfe]

Vagary,

You may be looking at the wrong devices. I recommend you take a look at Motorola's iDEN phones site--the J2ME implementation of various APIs in the phones are very complete and robust, including serial port interfaces, a half-dozen network protocols, crypto, interfaces to GPS hardware, etc. Yes, many of these are Motorola proprietary classes, but if you look at the MIDP 2.0 spec a lot of those proprietary features have become part of the general MIDP API.

Full disclosure: I work for Nextel. I also run their Developer Program.

Re:I thought Java was doomed

[bigredswitch]

"GC pauses and portability (consoles) are still issues for Java games"

I write mobile Java games for a living I have to say that pauses caused by garbage collection are not an issue I've come up against in modern (12 month old) phones. And portability isn't too much of an issue either, sure screen sizes are different and manufacturers API differ but it's not *that* problematic.