Parsing XML in J2ME

July 1, 2008 by ovidiu

Intro

            When it comes to exchanging information in the digital world, XML has long been praised as The Great Unifier. Being text-based (thus almost platform-independent) and able to represent any kind of data imaginable, XML turns interoperability and compatibility into goals within grasp. Other benefits, such as savings in both time and money, should also be noted. XML has been around for some time now, and it’s likely it won’t go away anytime soon.

            Now, while XML was busy igniting a revolution in interoperability, another technology was hard at work changing the very way we look at pocket-sized devices such as cell phones. Yes, I’m talking about J2ME. Bringing the power and philosophy of Java to something the size of a candy bar is no easy task, but J2ME has more than proven itself up to the challenge.

            So now, thanks to J2ME, you have billions of devices, all eager to talk to one-another and to exchange information with servers on the internet. And thanks to XML, they can all speak the same language and exchange information in a clear, easy to understand fashion.

Things to look for in a J2ME XML parser

            One of the reasons XML is useful is because it is easy to parse, both by man and machine. There are XML parsers for virtually any language and platform imaginable, and J2ME is no exception. However, being J2ME-based, they are subject to more stringent restrictions than parsers written for desktop platforms. That being said, the ideal J2ME parser should be:

• Small in size: smaller .jar files means a larger potential user-base, lower download times, faster load-times and more. In the mobile world, if it’s smaller, it’s better.
• Easy on resources: while J2ME is as generous as Java when in comes to advanced programming features (threads, OO, etc), J2ME devices have nowhere near the same generosity (in terms of runtime memory and CPU speed) that their larger counterparts have. J2ME code must be very resource-efficient to be worth using.
• Easy to use:  there’s a reason we use J2ME and not ASM to program mobile devices: writing code in J2ME is easy and intuitive (most of it, anyway). Likewise, using code already written in J2ME should be easy and intuitive.
• Packed with the right features: offer too little, and your code is not worth using. Offer too much, and your code will become so slow and cluttered that it will not be worth using.

 

One thing worth remembering is that there are three types of parsers:

• Pull parsers “pull” information out of the document in much the same way you would eat cookies off a conveyor belt: one piece at a time. These parsers require you to guide them at every step, telling them what to pull next and how to pull it.
• Push parsers “push” the information to you. They go through the entire document, and every time they encounter something of interest they push that information back to you, along with information about its position within the document.
• Model parsers parse the document on their own, and create an in-memory representation of the document using nested objects which you can then manipulate at will. Their biggest drawback is that they are generally more memory and CPU intensive (sometimes quite a lot more).

 

All three types of parsers have their ups and downs, depending on the scenario you’ll be using them in.

Potential candidates

The native approach: JSR 172

 

            The good news first: yes, J2ME provides native XML support through JSR 172 (also called J2ME Web Services Support). However (and here’s the bad news) it is not supported by all devices. Some very popular devices, such as Nokia’s 6230i, do not support JSR 172.

            JSR 172 is a good choice for those devices that do support it, because it offers improved performance (since it’s native and possibly platform-optimized), smaller .jar size and the comfort of using a standardized tool. However, not being able to run your application on every device is a very large downside.

            Granted, most recent devices (devices out in the last year or so) do support JSR 172 … but what about the rest? I personally would not use it. Also, JSR 172 is a push parser, and I personally prefer the other types of parsers.

kXML parser

 

            kXML seems to have struck a good balance between features, resource consumption and ease of use. It’s a pull parser, so most likely your code will reflect the structure of the documents you’ll be parsing. This makes it easier to use for first-timers, because it’s more intuitive to use and has, in my opinion, a much smootherr learning curve than push parsers.

            It is 10 KB in size (when obfuscated & compressed), so .jar size is not an issue for most devices. It was designed for use in mobile environments, offering (for example) the possibility of parsing WAP binary encoded XML and having an optional “relaxed” parsing mode, suitable for parsing not well-formed HTML documents without the need of an additional parser (thus saving on .jar size). It is also fast.

            kXML skips on certain features less likely to be used in mobile environments. For instance, its error checking is not so strict, meaning that some documents may pass as valid (documents having ‘]]>’ contained in text content are one example) when in fact they are not. These cases are rarely encountered in the real world, especially when considering that J2ME applications are generally given well-formed XML to begin with.

            kXML is a good overall solution. It does not shine on any single aspect, but it also doesn’t have any major drawbacks. Also, the fact that most internet tutorials on J2ME XML parsing use kXML means that it’s widely adopted and that you’ll most likely easily find information concerning it. kXML is available under the BSD licence.

 

Website: http://kxml.sourceforge.net/

 

kNanoXML

 

            kNanoXML is based on the NanoXML parser, but is modified (well, patched actually) to be used with J2ME. Being derived from a J2SE codebase, it performance and footprint are most likely not on-par with parsers created specifically for J2ME. However, its feature list includes generating XML, something no other J2ME parser I’ve found can do. If robustness and completness is what you’re looking for, and you are willing to sacrifice memory and performance for this, then kNanoXML might be for you.         

            One thing to remember is that NanoXML automagically generates the entire document tree in one function call, using nested XMLElements. This might be considered as both a plus or a minus, depending on the situation. One the one hand you have the entire generated XML tree at you disposal in just one function call, which leads to flexibility and cleaner code. On the other hand … well, you have the ENTIRE generated XML tree in memory, which might mean memory and performance issues, since J2ME objects aren’t exactly cheap memory-wise and CPU-wise.

 

Website: http://nanoxml.sourceforge.net/orig/kvm.html

 

Xparse-J

 

            Small in size, it is a small model parser, just over 6 KB in size. Looking at the example code provided on the Xparse-J homepage it looks to be very string-intensive, and we all know how much J2ME likes string processing. Other than that, it looks pretty good, and has one interesting feature (it personally made me smile, when I compared it to the other parsers): the way you navigate the document tree. See the example provided on the homepage for details.

 

Website: http://www.webreference.com/xml/tools/xparse-j.html

 

 

All the others

 

            Under this heading fall all other J2ME XML parser projects. Most of them provide little to no documentation, are not widely-known and quite obscure. To use one of them would be, in my opinion, foolish. They are neither the smallest, the fastest or the most feature-rich parsers available … so what have they got going for them? Nothing.

 

Website: none

 

DIY

 

            I’m a big fan of DIY projects. I consider them a great investment. You learn a great deal from them, you get the satisfaction of doing something yourself, you might just end up having something tailored exactly to your needs and you have something to brag about to you friends/coworkers/whatever.

            And in this case, this is something I might just recommend. First of all, XML parsing isn’t exactly rocket science. Second, you and you alone know the exact requirements and restrictions of the project you’re working one, and thus you are able to create the PERFECT tool for the job. And if some restriction, like memory or CPU usage, is really-really tough to manage, writing your own parser to deal with that restriction might very well be the best solution.

 

Website: your own

 

Theory vs Real-world

 

            Let’s face it, we say that J2ME apps should be small and lean and mean. They should be highly optimized, in terms of both memory and CPU usage. And indeed, five years ago, they NEEDED to be. However, things have changed.

            Most mobile phone users change their phone at least on a yearly basis. This means a huge rate of adoption. This means faster, cheaper, more powerful phones. This means that your application doesn’t need to be 5KB in size and run on a 20 MHz CPU. This means the code you use doesn’t have to be all that resource-efficient anymore. Feel free to spoil yourself and feast on those CPU cycles and KB of memory. Granted, it’s not a good idea to get fat, but there’s no point in starving yourself when there’s plenty around to eat.

            What the above mean from a J2ME XML parser point-of-view, is that you can start focusing a little bit more on ease-of-use and functionality, and a little bit less on resource consumption. While this attitude is greatly project-dependent, in the case of J2ME XML processing you’ll no longer find yourself desperately searching for that magical does-everything-requires-nothing parser. You’ll simply use the tool you’re most comfortable with.

 

Final word

 

            Parsing XML on mobile devices is not only possible, it’s easy. While the options are more limited than in the desktop world, the truth is that they do exist, and that they do manage to do their job quite well. And things are only going to get better from now on. So go ahead and XML-ize your J2ME project. J