If you want to skip all my stoopid writing and get to the point it’s right down towards the bottom.
If you write J2ME (or JavaME, or JME, or whatever the heck Sun wants to call it these days) code on a Mac OS X system then you’ve probably hit your head where I just did once or twice. See I’m new to Mac, new to OS X, new to mobile development so these things are just coming to me. On the Mac you will find no support for the Antenna library. Instead we have Michael Powers (who I’m about to contact) who has taken the liberty of creating an emulator/SDK for JavaME that works on OS X. Great idea except there’s no equivalent for Antenna. so now you got smarty-pantses like me roll their own support for things like writing JadFiles. I actually took the mpowerplayer Java code for the build logic and tried to clumsily wrap it in an Ant task. What I do is something that feels like the most obvious answer but what it comes down to is a subtle problem. I’ll drop the skinny on ya’ to see if you come to the same conclusion I did. (If you see the problem before I point it out keep your mouth shut so the slow people in back can catch up!)
In Java you got this defacto standard that every app be bundled as a Jar file. (While you can always distribute your class files without jarring them and force a CLASSPATH setting on your user community nobody does this anymore because it’s considered as impolite as passing gas and/or breaking out in laughter at someone’s eulogy.) In the jar file you have this cool thing called a manifest file… typically named in all caps MANIFEST.MF and situated conveniently in your jar. I know I’m boring you Java experts out there but bear with me… this is going somewhere. The manifest is just a text file with name/value pairs where the name and value are separated by colons. Now in JavaME (or J2ME, or JE micro edition, or whatever the fancy name is) you have another requirement, or standard or whatever, to include another cool file call a jad file. A Jad file is a Java Application Descriptor that describes your JME application to the device that loads it. It is just a text file with name/value pairs where the name and value are separated by colons. Java Micro Edition specifies that you include the following name value pairs in your Manifest: MIDlet-Version, MIDlet-Info-URL, MicroEdition-Configuration, MIDlet-Name, MIDlet-1, MIDlet-n… etc. Java Micro Edition specifies that you include the following name value pairs in your Jad file: MIDlet-Version, MIDlet-Info-URL, MicroEdition-Configuration, MIDlet-Name, MIDlet-1, MIDlet-n… etc. Would you look at that! I just copied and pasted a sentence. So what would any hard core Java dude do when he’s forced to copy/paste? No! Not start an inheritance heirarchy! Reuse the first thing in the second situation! My superior Java programming skills told me it would be wise to create the manifest using Ant’s Manifest task and then copy and pass it through another homegrown Ant task to add the final attribute required in your Jad as specified by the Steve McNealy MicroE spec. That would be the MIDlet-Jar-Size attribute which you can only discover by building a Jar file with your Java classes in it. So that’s what I did. Makes sense right?
Today I ran across a problem that required I consult with a much more senior (both in age and experience… sorry Joe but you’re older than me) developer to figure out. While it makes logical sense to reuse one file format which is so similar to another that they could pass as twins there’s always the subtle gotcha. Nobody called me at 2am in the morning following the day I decided copying would work to inform me that the Manifest spec says somewhere that a line may not be more than 72 characters in length without breaking to the next line via a fancy continuation sequence! It took the insight and cranium power of my more senior colleague (who immediately saw the problem… I mean in less than 60 seconds… the time it would take to make Ready-Pop) to figure out that my Jad file was following the manifest spec. You see while both the manifest and the Jad specs are soooo doggone similar, there’s that wrinkle in the manifest spec (that probably dates back to somebody’s old Win95 machine or Cobol program limitation) that does not (and should not) exist in the Jad spec. So when I went to include an application level parameter, which by the MIDlet spec is introduced via custom name value pair in your Jad file, that happened to include a little more than 72 characters (it was a server URL) the extra characters were wrapped on another line in both my manifest and my Jad. Since the Jad spec doesn’t say anything about wrapping (it might include a bit about rapping) my application only received part of the parameter and started to do the wop. (The wop was a popular hip-hop dance back in the late 80’s early nineties that I believed followed break-dancing. Who the heck does the wop nowadays? I’ll tell you who! My application does it when you pass it crazy server URLs! I guess nobody told the app that the wop was played out by the time I graduated high school.)
I really should start making my point early on in these long winded posts. In summary I learned that you can’t make a Jad out of a manifest no matter how well the manifest’s underwear fit on the Jad. These two things are different even though they are the same. I mean they work different even though the contents are similar. Well, I should say they work the same but the spec is different. Well the spec is pretty much the same but laid out slightly different. I mean they’re kinda the same but in different ways… I mean… aww can it! Just make sure you don’t trip over the 72 character thing in your manifest when you create your Jad.