Related link: http://simonstl.com/projects/tam/
Armed with a brand-new Palm m125 and a copy of Kim Topley’s excellent J2ME in a Nutshell, I set out to build a very simple SVG viewer and an interface for collecting information in the forest. I’m not nearly there yet, but I’m surprised to find myself enjoying what sounded like a difficult environment.
I’d picked up a Palm V at JavaOne a few years ago when they were first announcing this stuff, and stopped paying attention when it seemed like Java for the Palm got lost in more ambitious projects. Around the beginning of this year I noticed that J2ME, at least in its smallest CLDC/MIDP incarnation, was available. Around June, I finally got around to downloading it and starting to poke at it. (Sadly, I’m stuck for now doing my J2ME work on Windows, since the Mac OS X Java doesn’t provide J2ME support.)
The UI tools are primitive, and interface results vary drastically from device to device. Still, they work pretty nicely, and the low-level UI offers just enough features just enough of a toolkit to let me show people a graphic rendition of the information they’ve entered - trees in a forest. Working with integer-only math is a bit tricky when I want to create plots based on compass coordinates, but it just takes some extra thought.
The one piece of my J2ME work that’s now available is the Tiny API for Markup, a not-quite-XML-compliant parser that will be one of the bases for my SVG work. After doing this, I can see why Jon Bosak kept telling the XML 1.0 group that XML had to be processable on PDAs - though I think XML misses the J2ME mark. (A processor in C would likely be more compact and have more space, so they did okay for PDAs in general, I guess.)
Working in J2ME means do more with less, and has really illuminated specifications in a way I wasn’t capable of doing before. The difficulties in the XML spec become much clearer, SVG Tiny starts to look huge, and things which might have looked reasonable in the ever-faster ever-more-bloated environment of PCs become plainly stupid. While I miss a few things (like Java 2 Collections), for the most part, it’s a privilege to work in a leaner environment for a while. I doubt this will sweep the computing world, but maybe it should.
Is less more?
I know exactly how you feel.
I know exactly how you feel. My own research into, and at times outright yearning for, a simple and streamlined desktop apps [http://www.mplode.com/tima/archives/000064.html] is a direct result of my work in mobile computing and more particularly J2ME. Working with J2ME really makes you think about what really is necessary in providing the solution as opposed to whiz-bang features and other forms of programmatic kung fu. What's more amazing to me is how incredibly small and lightweight functional applications can be relative to what we have on the desktop. Its made me come to the realization that as programmers we have, perhaps subconsciously, become far too reliant on the every increasing resources the Intel, Microsoft and Dell tell us we need.
This is not to say that Photoshop or a full-featured web browser can be written in a 35k MIDlet. For some applications this approach is not really feasible. Nonetheless most application code are interfaces with some data handling logic. Coupled with Web services to a robust backend, these applications should be quite small and very quick on their "desktop mainframes" most users have on their desktop. If it weren't for the 20 MB download required, I would say the .NET Framework in some ways demonstrates. The MIDP KVM and core libraries are measured in KBs not MBs.
MIDP is a bit too spartan and extreme for use on the desktop. With the basic and limited GUI provided by MIDP, you will not win any design contests. MIDP is just one profile (and the smallest for that matter) in the J2ME world. In the J2ME connected device configuration or CDC (MIDP is in the Connect Device Limited Configuration or CDLC) there are profiles such as the Personal Basis profile, that have richer, yet highly streamlined, APIs that might be more appropriate for desktop application. (J2SE may be fine for developing JBuilder, but its just too fat and overkill for its own good. Don't even get me started on Applets either.)
Are you aware of the kXML 2 [http://kxml.org/] parser? Its substantially smaller then your TAM. (~6 KB I believe) kXML a simple pull parser rather then Simon's SAX2-like parser. The next version of MIDP that is in the works, MIDP 2.0 [http://www.jcp.org/jsr/detail/118.jsp], will most likely include an XML parser that I believe may be based on kXML. Additionally the JCP has released or are developing several extension APIs that can be added on an as needed basis -- all in the tens of KB size range.
The uses of XML over expensive slow and unreliable networks is an issue that has not received enough attention in my mind particularly in the area of mobile computing and Web services, a topic I have voiced my reservations about. [http://www.mplode.com/tima/archives/000005.html] Jeff Bone has recently been writing about "XML sucking" and in his recent post [http://www.oreillynet.com/pub/wlg/1858] points to XTalk a "semi-parsed, pseudo-binary representation of an XML" from IBM Labs. WAP employed a similar tact with its WAP Binary XML (WBXML) specification. While attending the Wireless Enterprise Seminar in Atlanta this May, I saw Adam Bosworth present a wireless application framework powered by J2ME using a "binary DOM representation" to communicate to its ultra thin client app. JXTA uses a binary format for its J2ME client, but I'm unsure if it is a tokenized binary representation of XML like the others.
While XML purist probably wince at this ideas, they seem like a reasonable comprise given the constraints of the mobile computing and making XML viable while remaining true to its core principles. I only hope that we settle on one standard method for this encoding.
[Adapted from weblog post at http://www.mplode.com/tima/archives/000081.html.]
Thanks, and
yes I'm aware of the kXML parser. I went looking for J2ME parsers at the start of this project and just didn't find anything that felt right.
I've not yet begun to optimize the TAM parser, and suspect I can probably chop out at least 5k, depending on what I'm willing to throw overboard. (Namespace support alone added 3k.) It's really just a start, and I'm well-aware that I supported more of XML than most J2ME developers are likely to want.
On the push-pull side of things, I'm pretty solidly a push person. Maybe the pull angle doesn't work with how I think about XML, or maybe I've just spent too much time writing SAX filters.
On binary formats, yes, I'm definitely an XML purist, and I've not yet seen a binary representation of XML that makes much sense to me. On the other hand, there's lots and lots of room for shared binary formats that don't pretend to be XML, and I hope to see more development in that direction in the future.
TinyLine
Speaking of SVG graphics in J2ME, I just wanted to point out TinyLine (http://www.geocities.com/tinyline/).
early experiment
I just knocked 3.4K off the parser's jar file by striking namespace support and chopping out support for comments. Not a bad start, more to come.
TinyLine very cool, but
the PersonalJava implementation it runs under is a lot more capable than the J2ME MIDP/CLDC profile. I'm looking forward to seeing a new J2ME profile in the same size range as PersonalJava, though!
The next generation of Personal Java is called Personal Profile
PersonalJava was developed before the Sun developed the configuration/profile approach to J2ME. Hence the name was changed to the Personal Profile [http://jcp.org/jsr/detail/62.jsp] to fit into that scheme. I don't believe a reference implementation is available yet. Its close cousin, the Personal Basis Profile [http://java.sun.com/products/personalbasis/] does have a reference implementation available.
MIDP 2.0 Proposed Final Draft released today.
The proposed final draft of the MIDP 2.0 specification was released today. It can be found here: http://jcp.org/aboutJava/communityprocess/first/jsr118/index.html
OT: J2ME and Mac OS X
Not really the point of the article, but Simon writes: "Sadly, I'm stuck for now doing my J2ME work on Windows, since the Mac OS X Java doesn't provide J2ME support."
Wouldn't it be more fair to write "the J2ME dev kit doesn't support Mac OS X"? It's Sun/JavaSoft that chose to leave Mac-based developers out in the cold by not bringing over the kvm or other dev tools to OSX.
BTW, On the main point of the article -- it must interesting to work in a "small" environment again. I recently allocated a 100KB buffer for wrangling MP3's and chided myself that "my first computer only had 32KB total RAM!"
--invaliidname
OT: J2ME and Mac OS X
As far as I understand you should be able to use J2ME under Mac OS X since February 2003:
http://mpowers.net/midp-osx/
Gerhard