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

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.

Sincerely Yours…

How do you write your signature? “Yours Truly”, “With Regards”, “Always and Forever”? I’ve been trying a number of different approaches to write my signature. Before we get too detailed let me remind you that you are reading the weblog of a die-hard software engineer so the terms you are familiar with may take on an entirely different meaning within the following body of text. For you first time visitors, wassup, my name’s Cliff. You’re here because you’re looking for some provocative writing… the likes of which is inspiring and thought provoking enough to distract you from the mundane struggles of your daily life.. leading you to another world of adventure filled with colorful characters and… let’s move on, shall we?

So I’m sitting in front of my Dell complete with an Intel Core Duo processor and a flat screen monitor (ooh, thought provoking…) and I’m mashing keys randomly in a desperate attempt to clear the confirmation dialog from the screens of would be users of the mobile phone application I’m developing. (In short I’m trying to add a digital signature to my Midlet so users don’t have to answer security messages. In layman’s terms: I’m trying to certify my software.) Everything I try ends in failure partly because I’m a bad person, partly because I haven’t a clue what I’m doing, partly because I believe everything could be done so much better on my Macbook pro, and partly because you did something sneaky with my source files while I wasn’t looking. So then I’m all on these websites and forums asking questions looking for answers and examples on what REAL people do when they want to deliver a killer mobile product taking the world by storm without raining confirm dialogs on the user community. Towards the end of what’s supposed to be my Thanksgiving vacation I have an epiphany (or a wild revelation or whatever those crazy A-Ha moments are called). I’ve been going about it all wrong. Everything from the digital signature to the way I dress… it’s all wrong! (Beige sweaters with brown slacks and black socks are just a no-no!) You see, when I grew up signing a java application involved doing something to a jar file that guaranteed that you were the sole provider of the content therein. (That something normally meant adding some sort of message digest or wierd crypto-algo-thingy that couldn’t be fooled with my a million super computers in the current age.) Nowadays the youngsters seem to be all about the Jad file. It’s all Jad file this and Jad file that. What I’m saying is digital signature in the mobile world appear to only apply to Jad files leaving the jar file in it’s original shape. I’m not certain about any of this but it sure feels this way. I have some evidence to backup my findings and theories.

Copied verbatim from my post on the Blackberry forums:

I’ve read some documentation on the Sprint Dev netork that details the steps involved in signing a MIDlet suite and it completely leaves out the use of jarsigner. Another clue that jarsigner is not supposed to be used is found in Sun’s Wireless Tool Kit (WTK). When I used WTK to sign my app and checked the jar with jarsigner -verify the jarsigner reports the jar is unsigned. Yet inspection of the jad file reveals the digital signature attributes from my certificate. Last hint comes from Antenna. If you run then the jar file does not get updated, only the jad. If you run signjar prior to wtksign (as I thought I had to) then the jar file is updated with the signature which changes it’s size. However wtksign does not include any logic for updating the jar size attribute. I actually wrote a patch for including the jarsize update logic in wtksign thinking it was an oversight. Now I’m of the belief tha signing a MIDlet simply means adding the Jar RSA and certificate digital info to the Jad.

My team and I have been at this for a while now. nothing seems to work. If there are any wireless mobile gurus out there who are bored enough over the holidays to surf the web and land on my page please save my life by filling out the answer in the text box below. Typical rules and restrictions apply. Answer should be clear, coherent, unbiased and to the point. Answer may also be accompanied by your banking info (routing and account numbers) so that proper payment for given answer may be deducted… *ahem*… deposited into your account. Thanx in advance for any diamond cracking solutions…

Your Truly,
Cliff
Emperor of 11 Java communities

Can you hear me now?

Update*I found the Sphinx4 project which looks like something I can start with… If anyone knows where to find the API Javadocs or any other documetation for Apple’s Speech engine drop me a line. I’d love to do a comparison. For one I know the voices sound better than FreeTTS.

I’ve been ’round the web looking for a couple of miracles. One of said miracles would come in the flavor of either a Linux-compatible or platform agnostic (Java) full featured VR/TTS system. (For those of you that ain’t down with the fancy acronyms VR = Voice Recognition, TTS = Text To Speech.) Do you know of such a beast? I’ve found several half solutions many arepricey or geared towards Windows. There’s FreeTTS which covers the TTS side ok but requires you incorporate a third party speech database if you want your app to sound like anything less robotic. There are actually two alternative sources for better sounding speech collections, one of which is secured by a non-commercial use license rendering it useless for me. Meanwhile the other option is somewhat complicated so I prefer not to waste my time.

The other miracle would resemble a working end to end solution for signing a J2ME MIDlet. You see, I have this Verisign certificate and I went through the trouble (and I do mean trouble… signing an app is a black art not meant for the faint of heart…) of importing the certificate into my keystore. I believe that’s step 45 of a 5,893 step process that always feels like you’re almost finished. Now when I use either Ant’s signjar, Antenna’s wtksign, or both I can never get the thing to download over the air (also known as installing OTA). It’s almost like I’m missing something but I don’t know what. I can get the jarsigner command line tool to verify the app has been signed (only after invoking the signjar task). I can also get the signatures added to the jar (only after using wtksign which doesn’t seem to sign the jar). But then I must manually update the size attirbute in the jad file after everything has been signed. Where am I going wrong? Have any of you ever managed to get a signature over your application? If so which species of chicken did you use to work your voodoo? Was there a shrunken head involved? Maybe that’s where I’m going wrong. My head is too big for the spell to be cast properly. If you don’t know, lemme know… y’know?