Eclipse: Multiple Problems Have Occurred


So I’m working on some Blackberry development and I’m using the MTJ plugin stuff for Eclipse, right? I’m running things in the debugger using the WTK simulator. Now I wanna add a watch point. I add a watch on a local variable with no problem. Then I right click an instance variable and select “watch”. Eclipse has multiple problems:

Eclipse Has Multiple Problems
Eclipse Has Multiple Problems

Why can’t Eclipse process its asynch thread queue? Why should I care? I’ve posted tough problems like this before and sometimes one or two of you chime in with helpful advice. I don’t normally use Eclipse but I’m trying it for size during this project. Can somebody weigh in here? Have you seen this before? Am I not supposed to watch variables in the debugger while running JME apps under WTK?

Build Native Blackberry apps natively on a Mac… using Maven!


Click here for the Maven Blackberry code behind this post.

Aight, I can’t help it! I’ve been itching to get this done for sooo long. If you’re into Blackberry development then you’ll understand just how absurd the above title sounds. Let me just throw intelliJ Idea into the mix as well then you’ll begin to see the big picture. Starting to do J2ME development, an experienced Java guy like myself has naturally gravitated towards a certain set of tools. Maven2 is hands down the only acceptable build system for a Java project, while Idea beats the pants off of Eclipse, and Windows boxes…? Forget it! Java runs practically double speed on a *Nix OS plus with the flash of OS X there’s no question as to what boots on a typical knowledgeable hard working Java developer’s box. All of these tools work well, and most of them work well together. BUT… BUT!!! Doing J2ME implies Windows and Ant all around so there’s gonna be either a divorcing of the toolchain or a boatload of integration issues. This weekend I fought through the biggest of the integration issues. And this morning I finally managed to build a Blackberry .cod deployable program… completely without Windows… using a Maven2 pom… natively on my Mac! I’ve been updating my blog incrementally with all of the individual pieces so I won’t go into too much detail here. At a high level I’ll explain the tools involved.

  • One Apple Macintosh (iBook, MacPro, MacbookPro, MacAir, whatever…)
  • One Blackberry (Preferably not Verizon because I don’t think they support J2ME)
  • One Windows install (I know, but this is only to extract the Blackberry tools! You can throw the whole thing away once you got the goods out of the JDE downloads. If you have a buddy that already has the JDE just steal it from him and skip this piece all together.)
  • One install of the Blackberry Java Development Environment (JDE).
  • One bottle of scotch (or wine) for to celebrate with.
  • One install of Maven2
  • Two tablets of asprin (to handle the hangover after you’ve spent the entire rest of the day celebrating with scotch or wine.)

I think that’s everything in the ingredients list. I’ll post back later with the recipe as time allows.

Didn’t get far


I was trying to develop J2ME with Maven on my Mac and blogging about it at the same time this past weekend. As an update I didn’t get too far. Fow what it’s worth, I did get a jar to build and I was able to manually upload it to a web server and then install it on my phone. The app worked but I still need to work out the kinks in automating the deployment process. I’m not sure if my Blackberry supports bluetooth installs and if it does I can’t find any documentation on it anywhere. On my drive in this morning I got to thinking about going the rest of the way and building a Blackberry plugin for Maven, one that would execute rapc and SignatureTool. I’ll have to prototype that from the command line first. More on that later. Back to regular work for now.

Run Progaurd Preverify os OSX?


Last night I went heads down researching and trying to figure out how to get passed the infamous preverify hurdle when building J2ME apps on OS X. I’m happy to report that I’m an idiot. I went through a boatload of trouble finding and almost attempting to fix a bug in the Antenna preverify task as it is slightly broken on OS X. I emailed everyone I could think of who had anything to do with Antenna, the Maven2-J2ME-plugin, and OS X. I submitted to blog posts along the way as I worked. Just moments ago I found what looks like a much more simple fix. The Pyx4ME project includes support for Progaurd which now includes a preverifier! I completely overlooked this option as I waded through mounds of documentation al from different sources regarding the best way to get past preverification on OS X.

I just ran a build with the Progaurd preverify option and it succeeded! I haven’t tried to run it or anything… that step comes next. I’m all too excited to see something actually run all the way through on my Mac.

I must admit that I’m slightly hesitant to take this approach due to the frailties our team has found with build time tools for J2ME. I’m speaking about issues with different JVMs, different obfuscators, too many obfuscators, lack of obfuscators, preverify configuration, application signing methodologies, and every other flaming hoop you have to leap through to get a decent build for a single device. I’d go into detail but I wanna keep plugging away to see how far my insanity can carry me.

Run WTK preverify on OSX!


In other breaking news I found a possible way to do true cross platform WTK development. If you’re not familiar OS X is the one platform where you really can’t do JavaME unless you’re really really savvy! The missing too is preverify. (An intel Mac compatible version can be found deep in the bowels of the PhoneME source download.) There’s the ol’ MPowerplayer preverify tool but that’s a little dated and out of synch with the WTK preverify tool. As a result you’ll find tools such as the EclipseME and Pyx4ME plugins won’t work with it. (Actually I believe EclipseME has Mpowerplayer support but I haven’t tried it.) I’m gonna keep this short so I can work on it. There’s this cat that’s blogging about doing cross platform JavaME development and I’m reading the blog now. On the blog he explains that the preverify tool in the PhoneME MR2 download under phoneme_feature/cldc/build/share/bin/darwin_powerpc/ will run on an Intel Mac. I just tried it on my 2.4Ghz MacPro running Leopard and I was able to bring up the help text from the command line. I’m loosely following his write up and a few other tutorials and links in an attempt to create a deployable Blackberry J2ME project using Maven on my Mac. We’ll see how far I get.

Run The Blackberry Compiler on Linux


Run rapc on Linux? Rapc for Mac? BSD and rapc?

Seriously, is this possible? I’ve been wondering for a while how feasible it would be to do J2ME development full time on a Mac or Linux machine and I dunno… it sounds reasonable at times and far fetched at other times. Today I found this gem. A guy supposedly got rapc, the Blackberry compiler, to work on a Linux machine. I’ve personally managed to sign Blackberry apps without requiring a full JDE install so maybe this is the other half of what I’ve been looking for? Here’s a shameless copy from the forum, in case it ever get deleted or lost:

1. Compile normal midp-2.0 midlet with J2ME SDK from Sun
2. set up $WTK_HOME to point to your J2ME install, $RIM to point to
your JDE/MDS/classpath, and $APPNAME to your app name
4. cd to $WTK_HOME/apps/$APPNAME
3. run
PATH=$WTK_HOME/bin:$PATH \
java -jar $RIM/rapc.jar import=$RIM/net_rim_api.jar \
codename=$APPNAME -midlet jad=bin/$APPNAME.jad bin/$APPNAME.jar

Your .cod file will end up in current dir. bin/$APPNAME.jad will be modified to contain all
BB-specific info.

I’m looking to do something with this knowledge. I’ll post back if I ever come up with something.

Watch out… to all my Mac J2ME coding homies!


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?

But wait…
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.)

In summary…
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.